netdev - Re: [PATCH net-next v9 1/2] 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 PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

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

Date:   Tue, 12 May 2020 06:22:20 +0200
From:   Jürgen Groß <jgross@...e.com>
To:     Denis Kirjanov <kda@...ux-powerpc.org>, paul@....org
Cc:     netdev@...r.kernel.org, brouer@...hat.com, wei.liu@...nel.org,
        ilias.apalodimas@...aro.org
Subject: Re: [PATCH net-next v9 1/2] xen networking: add basic XDP support for
 xen-netfront

On 11.05.20 19:27, Denis Kirjanov wrote:
> On 5/11/20, Jürgen Groß <jgross@...e.com> wrote:
>> On 11.05.20 12:22, 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.
>>>
>>> synchronization between frontend and backend parts is done
>>> by using xenbus state switching:
>>> Reconfiguring -> Reconfigured- > Connected
>>>
>>> UDP packets drop rate using xdp program is around 310 kpps
>>> using ./pktgen_sample04_many_flows.sh and 160 kpps without the patch.
>>
>> I'm still not seeing proper synchronization between frontend and
>> backend when an XDP program is activated.
>>
>> Consider the following:
>>
>> 1. XDP program is not active, so RX responses have no XDP headroom
>> 2. netback has pushed one (or more) RX responses to the ring page
>> 3. XDP program is being activated -> Reconfiguring
>> 4. netback acknowledges, will add XDP headroom for following RX
>>      responses
>> 5. netfront reads RX response (2.) without XDP headroom from ring page
>> 6. boom!
> 
> One thing that could be easily done is to set the offset on  xen-netback side
> in  xenvif_rx_data_slot().  Are you okay with that?

How does this help in above case?

I think you haven't understood the problem I'm seeing.

There can be many RX responses in the ring page which haven't been
consumed by the frontend yet. You are doing the switch to XDP via a
different communication channel (Xenstore), so you need some way to
synchronize both communication channels.

Either you make sure you have read all RX responses before doing the
switch (this requires stopping netback to push out more RX responses),
or you need to have a flag in the RX responses indicating whether XDP
headroom is provided or not (requires an addition to the Xen netif
protocol). Or I'm completely wrong and this can not happen due to the
way XDP programs work, but you didn't provide any clear statement this
being the case.

Juergen