From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 21:22:51 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 4FBAAA11 for ; Tue, 11 Nov 2014 21:22:51 +0000 (UTC) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D4CDFEAA for ; Tue, 11 Nov 2014 21:22:50 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id y19so1806032wgg.35 for ; Tue, 11 Nov 2014 13:22:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VANc12bKrToj/a9tBkLITtJP93lC1DPxplG2M8rh2y4=; b=uoe4dugd0Ga5gwYE/7frH+re7dgpdo+Leypb1CsGR1s4q1u+Bn3HGwoCIHPK9OYCkN hb7UW6Q3r2PgsF+L9KyzH3ypykqdTSN4CiuEH2WRwtVu72nhpmXl4Xm22N/eqElXUgSH R9M3N/2VWB4hX2LfvfDAQRgppaTTjRvWoMjvnbnmpurY7xizb+ODWp0YAnqh33hfGrUz qv930XRPAPvRe5EsvUfGpFwpBiJ+APiYd+DqBReM5jN6eePeqJ3P9xCzngIMDP10uvlN 02Bn9ED6SEFyC91D6lXtpB8Fhh8Gvg2p75vvv2FUviLXOutnRbdH6A00yreA25vClP7b 2XOQ== MIME-Version: 1.0 X-Received: by 10.194.85.83 with SMTP id f19mr34891727wjz.20.1415740969351; Tue, 11 Nov 2014 13:22:49 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Tue, 11 Nov 2014 13:22:49 -0800 (PST) In-Reply-To: <560E07EA-2506-487E-88DD-E2B9F7ED9792@lastsummer.de> References: <560E07EA-2506-487E-88DD-E2B9F7ED9792@lastsummer.de> Date: Tue, 11 Nov 2014 13:22:49 -0800 X-Google-Sender-Auth: Iw_H5kQrd0kmTrryznHY3vBqDrs Message-ID: Subject: Re: netmap: extension to store user data per packet/slot? From: Adrian Chadd To: Franco Fichtner Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current , 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: Tue, 11 Nov 2014 21:22:51 -0000 ... 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 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 > @@ -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"