RE: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V

[KY Srinivasan]

> -----Original Message-----
> From: David Miller [mailto:davem@xxxxxxxxxxxxx]
> Sent: Thursday, September 17, 2015 1:11 PM
> To: KY Srinivasan <kys@xxxxxxxxxxxxx>
> Cc: David.Laight@xxxxxxxxxx; alexander.duyck@xxxxxxxxx; Haiyang Zhang
> <haiyangz@xxxxxxxxxxxxx>; vkuznets@xxxxxxxxxx; netdev@xxxxxxxxxxxxxxx;
> linux-kernel@xxxxxxxxxxxxxxx; jasowang@xxxxxxxxxx
> Subject: Re: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V
> 
> From: KY Srinivasan <kys@xxxxxxxxxxxxx>
> 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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/