Thread (14 messages) flat view 14 messages, 3 authors, 2022-10-24

Re: [PATCH net] veth: Avoid drop packets when xdp_redirect performs

From: Toke Høiland-Jørgensen <hidden>
Date: 2022-09-29 12:08:48

Heng Qi [off-list ref] writes:
quoted
quoted
As I said above in the real case, the user's concern is not why the performance
of xdp becomes bad, but why the data packets are not received.
Well, that arguably tells the end-user there is something wrong in
their setup. On the flip side, having a functionally working setup with
horrible performances would likely lead the users (perhaps not yours,
surely others) in very wrong directions (from "XDP is slow" to "the
problem is in the application")...
quoted
The default number of veth queues is not num_possible_cpus(). When GRO is enabled
by default, if there is only one veth queue, but multiple CPUs read and write at the
same time, the efficiency of napi is actually very low due to the existence of
production locks and races. On the contrary, the default veth_xmit() each cpu has
its own unique queue, and this way of sending and receiving packets is also efficient.
This patch adds a bit of complexity and it looks completely avoidable
with some configuration - you could enable GRO and set the number of
queues to num_possible_cpus().

I agree with Toke, you should explain the end-users that their
expecations are wrong, and guide them towards a better setup.

Thanks!
Well, one thing I want to know is that in the following scenario,

NIC   ->   veth0----veth1
  |           |        |
(XDP)      (XDP)    (no XDP)

xdp_redirect is triggered,
and NIC and veth0 are both mounted with the xdp program, then why our default behavior
is to drop packets that should be sent to veth1 instead of when veth0 is mounted with xdp
program, the napi ring of veth1 is opened by default at the same time? Why not make it like
this, but we must configure a simple xdp program on veth1?
As I said in my initial reply, you don't actually need to load an XDP
program (anymore), it's enough to enable GRO through ethtool on both
peers. You can easily do this on setup if you know XDP is going to be
used in your environment.

-Toke
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help