From: Brendan Higgins <brendanhiggins@google.com>
To: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Cc: johannes.berg@intel.com, Richard Weinberger <richard@nod.at>,
Jeff Dike <jdike@addtoit.com>,
linux-um@lists.infradead.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
David Gow <davidgow@google.com>
Subject: Re: [RFC v1 1/2] um: drivers: remove support for UML_NET_PCAP
Date: Mon, 9 Dec 2019 15:40:04 -0800 [thread overview]
Message-ID: <CAFd5g448yZ5nSVLnN0gvsv3jLnhWG+dzJgvH1jdV+s2eTq4wxg@mail.gmail.com> (raw)
In-Reply-To: <15f048d3-07ab-61c1-c6e0-0712e626dd33@cambridgegreys.com>
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.
next prev parent reply other threads:[~2019-12-09 23:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-06 2:01 [RFC v1 0/2] um: drop broken features to fix allyesconfig Brendan Higgins
2019-12-06 2:01 ` [RFC v1 1/2] um: drivers: remove support for UML_NET_PCAP Brendan Higgins
2019-12-06 7:23 ` Anton Ivanov
2019-12-07 0:32 ` Brendan Higgins
2019-12-07 1:21 ` Brendan Higgins
2019-12-07 9:14 ` Anton Ivanov
2019-12-09 23:40 ` Brendan Higgins [this message]
2019-12-10 0:02 ` Richard Weinberger
2019-12-10 7:14 ` Anton Ivanov
2019-12-10 22:40 ` Brendan Higgins
2019-12-10 7:08 ` Anton Ivanov
2019-12-06 2:01 ` [RFC v1 2/2] uml: remove support for CONFIG_STATIC_LINK Brendan Higgins
2019-12-06 7:41 ` Anton Ivanov
2019-12-06 22:49 ` Brendan Higgins
2019-12-06 7:45 ` [RFC v1 0/2] um: drop broken features to fix allyesconfig Anton Ivanov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFd5g448yZ5nSVLnN0gvsv3jLnhWG+dzJgvH1jdV+s2eTq4wxg@mail.gmail.com \
--to=brendanhiggins@google.com \
--cc=anton.ivanov@cambridgegreys.com \
--cc=davidgow@google.com \
--cc=jdike@addtoit.com \
--cc=johannes.berg@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=richard@nod.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).