Erik Nordmark wrote:
> Garrett D'Amore wrote:
>
>> A lot of device drivers do msgdsize. Some (neptune, I'm looking at
>> you!) call it *a lot* (repeatedly) on the same packet.
>
> I don't understand how the fact that a driver is suboptimal means that
> we need to add some more complexity to the stack.
> I would seem better to fix the driver.
Normally I'd agree with you. But there are two problems with this:
1) sometimes the API is such that it is inconvenient to pass
information from one layer to the next by adding new function arguments.
2) there are multiple layers involved (VLANs, DLD, DLS, Mac, and the
driver), and they don't all cooperate well
The upshot of this, is that even in an optimal implementation, a driver
is going to have to walk that linked list *at least once* (and
frequently twice... it is often important to know the size of the packet
*before* you start copying it, because you need to allocate sufficient
space) and that the MAC/DLD/DLS layer is also doing its own checks.
It would really help to have a single way to pass the "trusted" (i.e.
prechecked/verified) size. Per packet gains might be tiny. But taken
at 1-2M packets per second, the gains may add up.
My own work with tiny packet forwarding demonstrates, I think, that each
cycle on the hot path counts. Wasting cycles recounting packet sizes
even just once is a crime. The fact that some drivers do it multiple
times is a testament is a tragedy. (And yes, I agree that there are
some drivers that are absolutely terrible with respect to per-packet
costs. Nxge takes the prize, I think, for the worse per-packet overhead
of any driver ever. But they claim "multicore scalability" as a
solution.... But that's another gripe.)
>
>> It would be very, very handy to have to full packet (maybe I mean
>> ethernet frame here) length pre-calculated.
>
> But it wouldn't come for free. As Darren pointed out, we'd have to
> update things in two places when changing the length of a packet. And
> such duplication is rife with problems - a bug where some code forgets
> to update both of them would be hard to track down.
>
> Complexity is the enemy. Performance is easier to deal with than
> complexity.
Normally I'd agree with you. But a simple function to return, for
example, the amount of room needed for the packet, would help device
drivers quite a bit.
-- Garrett
>
> Erik
_______________________________________________
networking-discuss mailing list
[email protected]
