Messages in this thread | | | Subject | Re: [PATCH 1/3] sfc: revert "reduce the number of requested xdp ev queues" | From | Edward Cree <> | Date | Mon, 12 Jul 2021 15:52:53 +0100 |
| |
On 12/07/2021 14:40, Íñigo Huguet wrote: > That's a good idea, which in fact I had already considered, but I had > (almost) discarded because I still see there 2 problems: > 1. If there are no free MSI-X vectors remaining at all, > XDP_TX/REDIRECT will still be disabled. > 2. If the amount of free MSI-X vectors is little. Then, many CPUs will > be contending for very few queues/locks, not for normal traffic but > yes for XDP traffic. If someone wants to intensively use > XDP_TX/REDIRECT will get a very poor performance, with no option to > get a better tradeoff between normal and XDP traffic. [snip] > So I think that we still need a last resort fallback of sharing TXQs > with network stack: > 1. If there are enough resources: 1 queue per CPU for XDP > 2. If there are not enough resources, but still a fair amount: many > queues dedicated only to XDP, with (hashed) locking contention > 3. If there are not free resources, or there are very few: TXQs shared > for network core and XDP
I think the proper solution to this is to get this policy decision out of the kernel, and make the allocation of queues be under the control of userspace. I recall some discussion a couple of years ago about "making queues a first-class citizen" for the sake of AF_XDP; this seems to be part and parcel of that. But I don't know what such an interface would/should look like.
-ed
| |