All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Ivanov <anton.ivanov@cambridgegreys.com>
To: Brendan Higgins <brendanhiggins@google.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: Tue, 10 Dec 2019 07:08:40 +0000	[thread overview]
Message-ID: <778d990f-5e07-b7af-498e-61f69c26f040@cambridgegreys.com> (raw)
In-Reply-To: <CAFd5g448yZ5nSVLnN0gvsv3jLnhWG+dzJgvH1jdV+s2eTq4wxg@mail.gmail.com>

On 09/12/2019 23:40, Brendan Higgins wrote:
> 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.
>
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/


WARNING: multiple messages have this Message-ID (diff)
From: Anton Ivanov <anton.ivanov@cambridgegreys.com>
To: Brendan Higgins <brendanhiggins@google.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: Tue, 10 Dec 2019 07:08:40 +0000	[thread overview]
Message-ID: <778d990f-5e07-b7af-498e-61f69c26f040@cambridgegreys.com> (raw)
In-Reply-To: <CAFd5g448yZ5nSVLnN0gvsv3jLnhWG+dzJgvH1jdV+s2eTq4wxg@mail.gmail.com>

On 09/12/2019 23:40, Brendan Higgins wrote:
> 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.
>
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/


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

  parent reply	other threads:[~2019-12-10  7:08 UTC|newest]

Thread overview: 30+ 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 ` Brendan Higgins
2019-12-06  2:01 ` [RFC v1 1/2] um: drivers: remove support for UML_NET_PCAP Brendan Higgins
2019-12-06  2:01   ` Brendan Higgins
2019-12-06  7:23   ` Anton Ivanov
2019-12-06  7:23     ` Anton Ivanov
2019-12-07  0:32     ` Brendan Higgins
2019-12-07  0:32       ` Brendan Higgins
2019-12-07  1:21       ` Brendan Higgins
2019-12-07  1:21         ` Brendan Higgins
2019-12-07  9:14         ` Anton Ivanov
2019-12-07  9:14           ` Anton Ivanov
2019-12-09 23:40           ` Brendan Higgins
2019-12-09 23:40             ` Brendan Higgins
2019-12-10  0:02             ` Richard Weinberger
2019-12-10  0:02               ` Richard Weinberger
2019-12-10  7:14               ` Anton Ivanov
2019-12-10  7:14                 ` Anton Ivanov
2019-12-10 22:40                 ` Brendan Higgins
2019-12-10 22:40                   ` Brendan Higgins
2019-12-10  7:08             ` Anton Ivanov [this message]
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  2:01   ` Brendan Higgins
2019-12-06  7:41   ` Anton Ivanov
2019-12-06  7:41     ` Anton Ivanov
2019-12-06 22:49     ` Brendan Higgins
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
2019-12-06  7:45   ` 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=778d990f-5e07-b7af-498e-61f69c26f040@cambridgegreys.com \
    --to=anton.ivanov@cambridgegreys.com \
    --cc=brendanhiggins@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.