Hello!
> Why should tcp_do_sendmsg() use MAX_HEADER but ip_build_xmit()
> use "(dev->hard_header_len + 15) & ~15)"? Shouldn't they have
> the same policy, whatever that policy is?
Policy is to reserve not _more_ than hard_header_len.
If driver prefers to hide its hard_header_len, but wants to have
whole linear skb however, it has to copy.
TCP has to reserve at least 128 bytes at head of any skb in any case
and it has to reserve the whole MTU at tail, so that there
are no reasons to try to save anything.
It is not the case for datagram sockets, and we may respect device hint
for them.
MAX_HEADER_LL is not hint, it is a static value, which can be used
and can be ignored. TCP uses this mainly due to specific of TCP
internals, i.e. by plain luck and this can be changed in future.
> I wrote new hard_header()
OK.
> and rebuild_header() routines
Not used really.
> but how can I support hard_header_cache(),
> header_cache_update(), and hard_header_parse() with
> struct hh_cache only supporting 16bytes of hh_data[] ?
hh_cache works only for 16byte headers. Sorry.
> It seems to me that many of the upcoming networking technologies
> (home phoneline, 802.11, bluetooth, other wireless)
> transport ethernet frames as payloads, taking on a few extra
> bytes/doing additional coding/etc . All want to present an
> ethernet interface and are happy to hide the details under
> their driver interface. This works great except for one line
> in ip_build_xmit() where it pedantically reserves hard_header_len
> instead of using MAX_HEADER_LL like tcp and being more forgiving.
> This forces those drivers to do a lot more work than they want
> or need to do, imho..
I repeat: if device wants more memory, it must give hint in hard_header_len.
If it prefers conspiracy, let it to copy in secret. 8)
MAX_HEADER_LL does not reflect real header length, it is not tunable
static value, which has no connection to devices used by system.
Alexey
|