On Tue, 2013-05-21 at 10:28 +0300, Eliezer Tamir wrote: > On 20/05/2013 18:29, Eric Dumazet wrote: > > On Mon, 2013-05-20 at 13:16 +0300, Eliezer Tamir wrote: > --- > >> +static inline void skb_mark_ll(struct sk_buff *skb, struct napi_struct > >> *napi) > >> +{ > >> + skb->dev_ref = napi; > >> +} > >> + > >> +static inline void sk_mark_ll(struct sock *sk, struct sk_buff *skb) > >> +{ > >> + sk->dev_ref = skb->dev_ref; > >> +} > > > > I do not see why it's safe to keep a pointer to a napi object without > > taking a reference, or something to prevent object being removed. > > > > Using a genid might be enough. (some counter incremented every time a > > napi is dismantled) > > I really like this approach and I tried it. > The main problem I had is that you need to increase the size of the skb > to store the generation id unless you stuff it in the flags2 bitfield. > There appear to be only 7 useful bit left there. > Is it OK to use them all up? > > > > Alternatively, use a napi_id instead of a pointer. > > I'm not sure I understand what you propose.
Oh well. To get a pointer to a struct net_device, we can use ifindex, and do a rcu lookup into a hash table to get the net_device. We do not need {pointer,ifindex} but {ifindex} is enough My suggestion is to not have skb->skb_ref but skb->napi_index : Its safe to copy its value from skb->napi_index to sk->napi_index without refcounting. All NAPI need to get a unique napi_index, and be inserted in a hash table for immediate/fast lookup. ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired