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