> One of the worst devices is the Broadcom one with 82 header and nowadays > 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
Attachment:
signature.asc
Description: This is a digitally signed message part
