Re: [B.A.T.M.A.N.] skb->priority and fragments

[Simon Wunderlich <sw@simonwunderlich.de>]

[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]

Hi Andrew,

On Wednesday 13 April 2016 14:14:16 Andrew Lunn wrote:
> [...]
> > There are two cases:
> > 
> > 1.) On the original sender, both fragments could adopt the priority as you
> > suggest. The code probably doesn't take care of that yet, so that could be
> > fixed.
> 
> I will cook up a patch for this.

Excellent!

> > 2.) On routers on the way, the priority could only be set based on the
> > first fragment, since the second fragment will not have a valid header to
> > parse. And unless we remember the priority from the first fragment, we
> > have no way to know to which priority we should set the second fragment.
> 
> I don't think remembering works. It looks like it fragments from the
> tail towards the head. So we are not going to receive the IP header
> until we get the last fragment.
> 

Ah,  you are deeper into that. But my hunch was also that it would be messy, 
since we can't guarantee the order of the fragments anyway.

> > I believe case 1 can be fixed easily, for case 2 I don't have an idea
> > right
> > now. :)
> 
> There is one reasonable option i can think
> of. batadv_skb_set_priority() extracts three bits of priority
> information, either from the TOS bits, or the 801.q header.
> 
> The fragment header is:
> 
> struct batadv_frag_packet {
>         u8     packet_type;
>         u8     version;  /* batman version field */
>         u8     ttl;
> #if defined(__BIG_ENDIAN_BITFIELD)
>         u8     no:4;
>         u8     reserved:4;
> #elif defined(__LITTLE_ENDIAN_BITFIELD)
>         u8     reserved:4;
> 	u8     no:4;
> #else
> #error "unknown bitfield endianness"
> #endif
>         u8     dest[ETH_ALEN];
>         u8     orig[ETH_ALEN];
>         __be16 seqno;
> 	__be16 total_size;
> };
> 
> Place the priority information into 3 of the 4 reserved bits. The
> receiver can then set the skb->priority of the fragment before passing
> it to the hard interface.

Ah, yes that sounds like an excellent idea! I like that. The default should be 
zero right now, which would also fit. :)

Thanks!
     Simon

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]