> One of the worst devices is the Broadcom one with 82 header and nowadays
quoted text
> actually DMAs this header from a separate memory location, so there this
> won't happen, but can we guarantee that all devices are programmable
> that way? We've seen lots of rather strange devices unfortunately...

The worst case is probably prism54 usb devices which by itself need 76
bytes headroom for the USB buffer, and then when we say run mesh on top
of it we'll need a total of 122 bytes. Needless to say, it cannot do s/g
operation.

The question is: how do we handle that? Do we reallocate the buffer in
the driver? That is well possible but makes it rather inconvenient for
driver authors. Also, mac80211 will still need 46 bytes of headroom and
12 bytes of tailroom in the worst case (so far, HT might require four
more.) If we skb_orphan() the skb right away we have essentially removed
all socket memory accounting, so that's pretty pointless.

Should we increase the LL_MAX_HEADER constant to 40 (no mesh networking)
or 46 for when 802.11 (with mesh networking) is configured into the
kernel? Most people probably don't run an IPIP tunnel over wireless yet
configure them in (especially distros) so that might be why we never saw
the problem before.

johannes