> Where is the patch that adds these new members to struct netdevice,
quoted text
> and where is the code that uses these new values?

Inlined below this time.

quoted text
> Anyways I see your basic idea and this may be the best way to handle
> the problem.  The invariants would be:
>=20
> 1) LL_MAX_HEADER has to include all of these bits.

Yes. Well, it has to be long enough for it, yes, but mac80211 has
drivers that want 100 bytes more headroom for themselves and probably
won't get added to LL_MAX_HEADER. But still putting that much into
needed_headroom is beneficial for many cases even if that means that
some packets will have to be copy-expanded. This, however, means that
you cannot put an assertion into dev_queue_xmit.

Also, taking into account tailroom isn't trivial because you need to
reserve the headroom but not the tailroom etc. I'm still thinking of a
way to avoid reserving tailroom completely when the hardware will handle
the crypto-checksumming but right now we don't have hardware that does
all crypto, only some algorithms. But we can even update
needed_headroom/tailroom on the fly.

quoted text
> 2) LL_RESERVED_SPACE*() has to take the new needed_headroom
>    into account.

Check. I added LL_ALLOCATED_SPACE() for the tailroom and used that in
places for the allocation. I'm fairly sure I didn't get all of them
though.

quoted text
> Your patch which I can't find, which adds netdev->needed_*, probably
> does all of that.  But I'm just making sure :-)
>=20
> Note that what would be really nice is if we could assert, in
> dev_queue_xmit, that the SKB has all of the necessary headroom, and
> give a WARN_ON_ONCE() backtrace if not.
>=20
> If we can ensure that, things like mac80211 and others will not need
> to skb_realloc_headroom() or anything like that unless they need to
> modify packet contents after skb->data and the packet is shared
> (ie. the pskb_expand_headroom(skb, 0, 0, GFP_*) case the TSO drivers
> use).

That would be nice, but I don't think it's possible.

johannes