netdev - Re: [PATCH net-next v4] xen networking: add basic XDP support for xen-netfront

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 18 Mar 2020 14:11:22 +0100
From:   Jürgen Groß <jgross@...e.com>
To:     Denis Kirjanov <kda@...ux-powerpc.org>
Cc:     netdev@...r.kernel.org, ilias.apalodimas@...aro.org,
        wei.liu@...nel.org, paul@....org
Subject: Re: [PATCH net-next v4] xen networking: add basic XDP support for
 xen-netfront

On 18.03.20 13:50, Denis Kirjanov wrote:
> On 3/18/20, Jürgen Groß <jgross@...e.com> wrote:
>> On 16.03.20 14:09, Denis Kirjanov wrote:
>>> The patch adds a basic XDP processing to xen-netfront driver.
>>>
>>> We ran an XDP program for an RX response received from netback
>>> driver. Also we request xen-netback to adjust data offset for
>>> bpf_xdp_adjust_head() header space for custom headers.
>>
>> This is in no way a "verbose patch descriprion".
>>
>> I'm missing:
>>
>> - Why are you doing this. "Add XDP support" is not enough, for such
>>     a change I'd like to see some performance numbers to get an idea
>>     of the improvement to expect, or which additional functionality
>>     for the user is available.
> Ok, I'll try to measure  some numbers.
> 
>>
>> - A short description for me as a Xen maintainer with only basic
>>     networking know-how, what XDP programs are about (a link to some
>>     more detailed doc is enough, of course) and how the interface
>>     is working (especially for switching between XDP mode and normal
>>     SKB processing).
> 
> You can search for the "A practical introduction to XDP" tutorial.
> Actually there is a lot of information available regarding XDP, you
> can easily find it.
> 
>>
>> - A proper description of the netfront/netback communication when
>>     enabling or disabling XDP mode (who is doing what, is silencing
>>     of the virtual adapter required, ...).
> Currently we need only a header offset from netback driver so that we can put
> custom encapsulation header if required and that's done using xen bus
> state switching,
> so that:
> - netback tells that it can adjust the header offset
> - netfront part reads it

Yes, but how is this synchronized with currently running network load?
Assume you are starting without XDP being active and then you are
activating it. How is the synchronization done from which request on
the XDP headroom is available?

>>
>> - Reasoning why the suggested changes of frontend and backend state
>>     are no problem for special cases like hot-remove of an interface or
>>     live migration or suspend of the guest.
> 
> I've put the code to talk_to_netback which is called "when first
> setting up, and when resuming"
> If you see a problem with that please share.

What happens if a migration is just starting when netfront has switched
its state to "Reconfigured"? Will the new device activation at the
target host work as desired? In which state will XDP be on the frontend
after that (i.e. is a direct state transition on the frontend from
"Reconfigured" to "Initializing" fine)? It should be spelled out in the
commit message that this scenario has been thought of and that it will
work.

> 
>>
>> Finally I'd like to ask you to split up the patch into a netfront and
>> a netback one.
> 
> Ok, will do.

Thanks.


Juergen