Messages in this thread | | | From | Brendan Higgins <> | Date | Mon, 9 Dec 2019 15:40:04 -0800 | Subject | Re: [RFC v1 1/2] um: drivers: remove support for UML_NET_PCAP |
| |
On Sat, Dec 7, 2019 at 1:15 AM Anton Ivanov <anton.ivanov@cambridgegreys.com> 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@cambridgegreys.com> 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@lists.infradead.org > > 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.
| |