Re: netmap: extension to store user data per packet/slot?

From: Adrian Chadd <adrian_at_freebsd.org>
Date: Tue, 11 Nov 2014 13:22:49 -0800
... I'm confused. Do you have the slot id already, right? Why not
allocate an array of userdata pointers somewhere else and just use the
netmap slot id as an indirection into that?



-adrian


On 11 November 2014 13:13, Franco Fichtner <franco_at_lastsummer.de> wrote:
> Hi Luigi,
> hi all,
>
> so I was running into logistics issues with netmap(4)
> with regard to zero-copy and redirection through pipes:
> working on a load-balancing framework revealed that it
> is very hard to track a packet's origins to later move
> it onward to the respective outgoing interface, be it
> another device or the host stack.
>
> Long story short: user data needs to be stored for the
> packet buffer or slot.
>
> There are three ways that I can see so far:
>
> (1) Allocate a netmap pipe pair for each interface,
>     in case of transparent mode also a pipe for the
>     host stack each.  That's a lot of pipes and
>     most likely insane, but it won't extend the ABI.
>
> (2) Store the additional data in the actual buffer.
>     That is sort of ok, but seems sluggish WRT cache
>     behaviour -- maybe the buffer won't be read but
>     it needs to be written.  Sure, we can store it at
>     the end, but there already resides the packet
>     timestamp if enabled (if I recall correctly).
>     Wouldn't extend the ABI per se, but might collide
>     with the timestamping....
>
> (3) Make room in struct netmap_slot itself like this:
>
> diff --git a/sys/net/netmap.h b/sys/net/netmap.h
> index 15ebf73..d0a9c0e 100644
> --- a/sys/net/netmap.h
> +++ b/sys/net/netmap.h
> _at__at_ -147,6 +147,7 _at__at_ struct netmap_slot {
>         uint16_t len;           /* length for this slot */
>         uint16_t flags;         /* buf changed, etc. */
>         uint64_t ptr;           /* pointer for indirect buffers */
> +       uint64_t userdata;      /* reserved storage for caller */
>  };
>
> It could also be broken down in two fields with uint32_t
> each; not sure what would be more sensible.  This of course
> requires an API bump, although it should be backwards
> compatible.
>
> Any feedback on this is highly appreciated.
>
>
> Cheers,
> Franco
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
Received on Tue Nov 11 2014 - 20:22:51 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:53 UTC