Re: [RFC v1 1/2] um: drivers: remove support for UML_NET_PCAP
From: Anton Ivanov
Date: Tue Dec 10 2019 - 02:08:55 EST
On 09/12/2019 23:40, Brendan Higgins wrote:
On Sat, Dec 7, 2019 at 1:15 AM Anton Ivanov
<anton.ivanov@xxxxxxxxxxxxxxxxxx> wrote:
On 07/12/2019 01:21, Brendan Higgins wrote:
On Fri, Dec 06, 2019 at 04:32:34PM -0800, Brendan Higgins wrote:
On Thu, Dec 5, 2019 at 11:23 PM Anton Ivanov
<anton.ivanov@xxxxxxxxxxxxxxxxxx> wrote:
[...]
1. There is a proposed patch for the build system to fix it.
So I just tried the patch you linked on the cover letter[1], and I am
still getting the build error described above:
arch/um/drivers/pcap_user.c:35:12: error: conflicting types for âpcap_openâ
static int pcap_open(void *data)
^~~~~~~~~
In file included from /usr/include/pcap.h:43,
from arch/um/drivers/pcap_user.c:7:
/usr/include/pcap/pcap.h:859:18: note: previous declaration of âpcap_openâ was here
PCAP_API pcap_t *pcap_open(const char *source, int snaplen, int flags,
Looking at the patch, I wouldn't expect it to solve this problem.
Are there maybe different conflicting libpcap-dev libraries and I have
the wrong one? Or is this just still broken?
2. We should be removing all old drivers and replacing them with the
vector ones.
Hmm...does this mean you would entertain a patch removing all the
non-vector UML network drivers? I would be happy to see VDE go as
well.
In any event, it sounds like I should probably drop this patch as it
is currently.
Thanks!
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938962#79
_______________________________________________
linux-um mailing list
linux-um@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-um
OK, looks like the pcap.h differs now as well.
I will fix that too. It looks like you need both a pcap fix and a
library linking fix for this to work.
The patch fixes the issue with the build system which no longer provides
the means for UML to specify extra libraries (I probably had an older
pcap version on the machine where I tested this).
IMHO frankly it is no longer necessary.
5.5-rc1 vector raw now has the facility to add/remove (including at
runtime) filters compiled with pcap outside UML. It was merged this week.
We now have the following line-up for vector drivers - EoGRE, EoL2TPv3,
RAW (+/- BPF), TAP and BESS. Speeds are 2.5 to 9Gbit on my machine
(mid-range Ryzen desktop).
If I figure out a way to get hold of the underlying tap raw sockets the
same way vhost does, TAP can probably go to 12Gbit or thereabouts. Same
applies to getting zerocopy working with raw.
As a basis for comparison I get 18Gbit on the same machine using vEth
and containers. 50% of that is actually a very decent number.
While vector drivers are not 1:1 replacements for the existing drivers,
you can achieve the same topologies and the same connectivity at much
higher performance - the old drivers test out in the 500Mbit range on
the same hardware.
IMHO we should at least mark them as "obsolete" and start preparing to
remove them.
Alright, I will send a patch out which marks the other network drivers
as "obsolete".
Clarification: Should I mark all UML network devices as "obsolete"
except for NET_VECTOR? Daemon and MCAST looked to me (I am not a
networking expert), like they might not be covered by vector.
They are not 1:1 replacements unfortunately.
However, in order to fix daemon I have to rewrite the switch from
uml-utilities too. It is beyond obsolete.
MCAST for 2 UML instances can be replaced by either GRE or L2TPv3, for
more than 2 you are better off introducing a proper switch.
I am OK if all old drivers are marked as obsolete at this point, so
please proceed with the patch.
Brgds,
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/