Messages in this thread | | | Subject | Re: [PATCH] xsk: add cq event | From | Björn Töpel <> | Date | Mon, 16 Nov 2020 15:31:20 +0100 |
| |
On 2020-11-16 09:10, Xuan Zhuo wrote: > When we write all cq items to tx, we have to wait for a new event based > on poll to indicate that it is writable. But the current writability is > triggered based on whether tx is full or not, and In fact, when tx is > dissatisfied, the user of cq's item may not necessarily get it, because it > may still be occupied by the network card. In this case, we need to know > when cq is available, so this patch adds a socket option, When the user > configures this option using setsockopt, when cq is available, a > readable event is generated for all xsk bound to this umem. > > I can't find a better description of this event, > I think it can also be 'readable', although it is indeed different from > the 'readable' of the new data. But the overhead of xsk checking whether > cq or rx is readable is small. > > Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Thanks for the patch!
I'm not a fan of having two different "readable" event (both Rx and cq). Could you explain a bit what the use case is, so I get a better understanding.
The Tx queues has a back-pressure mechanism, determined of the number of elements in cq. Is it related to that?
Please explain a bit more what you're trying to solve, and maybe we can figure out a better way forward!
Thanks! Björn
| |