> -----Original Message----- > From: David Miller [mailto:da...@davemloft.net] > Sent: Thursday, September 17, 2015 11:52 AM > To: KY Srinivasan <k...@microsoft.com> > Cc: david.lai...@aculab.com; alexander.du...@gmail.com; Haiyang Zhang > <haiya...@microsoft.com>; vkuzn...@redhat.com; netdev@vger.kernel.org; > linux-ker...@vger.kernel.org; jasow...@redhat.com > Subject: Re: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V > > From: KY Srinivasan <k...@microsoft.com> > Date: Thu, 17 Sep 2015 15:14:05 +0000 > > > I think I can achieve my original goal of not having any allocation > > in the send path by carefully using the memory available in the skb: > > Please stop flat-out ignoring David L.'s suggestion.
I am sorry; I did not mean to convey that impression. > > Have a pre-cooked ring of buffers for these descriptors that you can > point the chip at. No per-packet allocation is necessary at all. Even if I had a ring of buffers, I would still need to manage the life cycle of these buffers - selecting an unused one on the transmit path and marking it used (atomically). Once the transmit completes (as indicated by the transmit complete callback) this buffer needs to be marked free. I can certainly make these operations efficient and lock-free, but they are still at some level an allocation/free operation albeit potentially more efficient than having the kernel allocate the memory. > > If you play games with SKBs you will get burned. I will implement Dave L's suggestion. However, I am curious as to why you would consider my proposed usage of the skb headroom and the control buffer area in skb as non-standard usage. Regards, K. Y -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
