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