Messages in this thread | | | From | KY Srinivasan <> | Subject | RE: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V | Date | Thu, 17 Sep 2015 21:16:24 +0000 |
| |
> -----Original Message----- > From: David Miller [mailto:davem@davemloft.net] > Sent: Thursday, September 17, 2015 1:11 PM > To: KY Srinivasan <kys@microsoft.com> > Cc: David.Laight@ACULAB.COM; alexander.duyck@gmail.com; Haiyang Zhang > <haiyangz@microsoft.com>; vkuznets@redhat.com; netdev@vger.kernel.org; > linux-kernel@vger.kernel.org; jasowang@redhat.com > Subject: Re: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V > > From: KY Srinivasan <kys@microsoft.com> > Date: Thu, 17 Sep 2015 19:52:01 +0000 > > > > > > >> -----Original Message----- > >> 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). > > Have one per TX ring entry, then the lifetime matches the lifetime of the > TX entry itself and therefore you need do nothing.
Yes, I understand. Unfortunately, the ring buffer used on Hyper-V to send the packets to the host is not managed as a traditional TX ring entries - it is not fixed size and a given packet can wrap around and lastly, I think the management of space on the ring buffer is not tied to the act of completing the send operation. That is why we have an explicit "send complete" message.
I am working on moving the model to more closely match the hardware model but it will take some time. For now, I will implement a very light weight mechanism for managing the additional memory needed.
Regards,
K. Y > > That's the whole idea.
| |