lkml.org 
[lkml]   [2019]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC v1 1/2] um: drivers: remove support for UML_NET_PCAP
From
Date
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.

--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/

\
 
 \ /
  Last update: 2019-12-07 10:16    [W:0.500 / U:0.692 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site