Re: [PATCH][V2] libbpf: add support for canceling cached_cons advance

On Wed, Nov 25, 2020 at 10:02 AM Daniel Borkmann [off-list ref] wrote:

On 11/25/20 9:30 AM, Magnus Karlsson wrote:

quoted

On Tue, Nov 24, 2020 at 10:58 PM Daniel Borkmann [off-list ref] wrote:

quoted

On 11/24/20 9:12 AM, Magnus Karlsson wrote:

quoted

On Tue, Nov 24, 2020 at 8:33 AM Li RongQing [off-list ref] wrote:

quoted

Add a new function for returning descriptors the user received
after an xsk_ring_cons__peek call. After the application has
gotten a number of descriptors from a ring, it might not be able
to or want to process them all for various reasons. Therefore,
it would be useful to have an interface for returning or
cancelling a number of them so that they are returned to the ring.

This patch adds a new function called xsk_ring_cons__cancel that
performs this operation on nb descriptors counted from the end of
the batch of descriptors that was received through the peek call.

Signed-off-by: Li RongQing <redacted>
[ Magnus Karlsson: rewrote changelog ]
Cc: Magnus Karlsson <magnus.karlsson@intel.com>
---
diff with v1: fix the building, and rewrote changelog

   tools/lib/bpf/xsk.h | 6 ++++++
   1 file changed, 6 insertions(+)

diff --git a/tools/lib/bpf/xsk.h b/tools/lib/bpf/xsk.h
index 1069c46364ff..1719a327e5f9 100644
--- a/tools/lib/bpf/xsk.h
+++ b/tools/lib/bpf/xsk.h

@@ -153,6 +153,12 @@ static inline size_t xsk_ring_cons__peek(struct xsk_ring_cons *cons,
          return entries;
   }

+static inline void xsk_ring_cons__cancel(struct xsk_ring_cons *cons,
+                                        size_t nb)
+{
+       cons->cached_cons -= nb;
+}
+
   static inline void xsk_ring_cons__release(struct xsk_ring_cons *cons, size_t nb)
   {
          /* Make sure data has been read before indicating we are done
--

2.17.3

Thank you RongQing.

Acked-by: Magnus Karlsson <magnus.karlsson@intel.com>

@Magnus: shouldn't the xsk_ring_cons__cancel() nb type be '__u32 nb' instead?

All the other interfaces have size_t as the type for "nb". It is kind
of weird as a __u32 would have made more sense, but cannot actually
remember why I chose a size_t two years ago. But for consistency with
the other interfaces, let us keep it a size_t for now. I will do some
research around the reason.

It's actually a bit of a mix currently which is what got me confused:

static inline __u32 xsk_prod_nb_free(struct xsk_ring_prod *r, __u32 nb)
static inline __u32 xsk_cons_nb_avail(struct xsk_ring_cons *r, __u32 nb)
static inline size_t xsk_ring_prod__reserve(struct xsk_ring_prod *prod, size_t nb, __u32 *idx)
static inline void xsk_ring_prod__submit(struct xsk_ring_prod *prod, size_t nb)
static inline size_t xsk_ring_cons__peek(struct xsk_ring_cons *cons, size_t nb, __u32 *idx)
static inline void xsk_ring_cons__release(struct xsk_ring_cons *cons, size_t nb)

(I can take it in as-is, but would be nice to clean it up a bit to avoid confusion.)

Hmm, that is confusing indeed. Well, the best choice would be __u32
everywhere since the ring pointers themselves are __u32. But I am
somewhat afraid of changing an API. Can we guarantee that a change
from size_t to __u32 will not break some user's compilation? Another
option would be to clean this up next year when we will very likely
produce a 1.0 version of this API and at that point we can change some
things. What do you think would be the best approach?

Thanks,
Daniel