On 2 May 99 at 21:50, [EMAIL PROTECTED] wrote:
Thanks for reply.
> > So I have four questions:
> > a) Should not ethertap try reallocate skb as (for example) ppp does if
> > there is not enough space?
> It should not. Actually, I've just remembered that we agreed to
> kill this reservation of two bytes before frame but I forgot to make
> it :( It is my fault...
> Alan, what can you propose? Is it too late to fix it?
OK. There is problem that these two bytes are passed to userspace through
netlink :-( So if you remove them here, you'll have to add them in netlink.
> > b) Even if I do (a), ethertap will have to copy data on each IPX transmit
> > :-( It looks like that IPX should reserve more than
> > hard_header_len + header_length bytes. But how much? For
> > ethertap+IPX+any ethernet frame, rounding up to multiple of 16 as
> > ipv4/ip_output does, is sufficient. But I really think that code should
> > not rely on that there is at least two byte difference between header
> > size and header size rounded up to multiple of 16.
> It relies on the fact that IEEE 802.1 frames have broken alignment
> and stacks must take it into account. Because 802.1 is primary one
> on ethernet media, all the protocols not requiring alignment suffer.
> It is unavoidable.
> > d) Is there another solution which I oversight?
> Yes. Not to reserve these two bytes.
So what is better? Add two bytes reserve into IPX skb or add two bytes
plus align skb to 16? I do not think that move of adding these two bytes
from ethertap to netlink code is possible.
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
