From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 19:16:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07056AE0 for ; Wed, 12 Nov 2014 19:16:41 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB6BCB75 for ; Wed, 12 Nov 2014 19:16:40 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XodP9-000LEd-Ke; Wed, 12 Nov 2014 23:16:35 +0400 Date: Wed, 12 Nov 2014 23:16:35 +0400 From: Slawa Olhovchenkov To: Franco Fichtner Subject: Re: netmap: extension to store user data per packet/slot? Message-ID: <20141112191635.GA91736@zxy.spb.ru> References: <560E07EA-2506-487E-88DD-E2B9F7ED9792@lastsummer.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <560E07EA-2506-487E-88DD-E2B9F7ED9792@lastsummer.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-current@freebsd.org, Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 19:16:41 -0000 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"