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:   Mon, 23 Mar 2020 13:49:19 +0300
From:   Denis Kirjanov <kda@...ux-powerpc.org>
To:     Jürgen Groß <jgross@...e.com>
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 3/23/20, Jürgen Groß <jgross@...e.com> wrote:
> On 23.03.20 11:15, Denis Kirjanov wrote:
>> On 3/18/20, Jürgen Groß <jgross@...e.com> wrote:
>>> 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?
>>
>> Hi Jurgen,
>>
>> basically XDP is activated when you've assigned an xdp program to the
>> networking device.
>> Assigning an xdp program means that we have to adjust a pointer which
>> is RCU protected.
>
> This doesn't answer my question.
>
> You have basically two communication channels: the state of the frontend
> and backend for activation/deactivation of XDP, and the ring pages with
> the rx and tx requests and responses. How is the synchronization between
> those two channels done? So how does the other side know which of the
> packets in flight will then have XDP on or off?

Right,
that's done in xen-netback using xenbus state:
- in xennet_xdp_set() we call xenbus_switch_state to tell xen-netback to
adjust offset for an RX response.
-xen-netback reads the value from xenstore and adjusts the offset for
xen-netback
in xenvif_rx_data_slot() using vif->xdp_enabled flag.


>
>
> Juergen
>

Powered by blists - more mailing lists