On 11.05.20 19:27, Denis Kirjanov wrote:
On 5/11/20, Jürgen Groß <jgr...@suse.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
