Date: Wed, 12 Nov 2014 23:16:35 +0400 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: Franco Fichtner <franco@lastsummer.de> Cc: freebsd-current@freebsd.org, Luigi Rizzo <rizzo@iet.unipi.it> Subject: Re: netmap: extension to store user data per packet/slot? Message-ID: <20141112191635.GA91736@zxy.spb.ru> In-Reply-To: <560E07EA-2506-487E-88DD-E2B9F7ED9792@lastsummer.de> References: <560E07EA-2506-487E-88DD-E2B9F7ED9792@lastsummer.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 11, 2014 at 10:13:54PM +0100, Franco Fichtner 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.
I think need configurable (by sysctl) space recerved before packet.
This is may be used as user data. Or for insert VLAN/MPLS/QinQ/etc
headers.
More general: tilera have good api for this.
> 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
> @@ -147,6 +147,7 @@ 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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141112191635.GA91736>