On 17-04-24 05:14 AM, Simon Horman wrote: [..]
Jamal, I am confused about why are you so concerned about the space consumed by this attribute, it's per-message, right? Is it the bigger picture you are worried about - a similar per-entry flag at some point in the future?
To me the two worries are one and the same. Jiri strongly believes (from a big picture view) we must use TLVs for extensibility. While I agree with him in general i have strong reservations in this case because i can get both extensibility and build for performance with using a flag bitmask as the content of the TLV. A TLV consumes 64 bits minimum. It doesnt matter if we decide to use a u8 or a u16, we are still sending 64 bits on that TLV with the rest being PADding. Not to be melodramatic, but the worst case scenario of putting everything in a TLV for 32 flags is using about 30x more space than using a bitmask. Yes, space is important and if i can express upto 32 flags with one TLV rather than 32 TLVs i choose one TLV. I am always looking for ways to filter out crap i dont need when i do stats collection. I have numerous wounds from fdb entries which decided to use a TLV per flag. The design approach we have used in netlink is: flags start as a bitmap (whether they are on main headers or TLVs); they may be complemented with a bitmask/selector (refer to IFLINK messages). Lets look at this specific patch I have sending. I have already changed it 3 times and involved a churn of 3 different flags. If you asked me in the beggining i wouldve scratched my head thinking for a near term use for bit #3, #4 etc, I am fine with the counter-Postel view of having the kernel validate that appropriate bits are set as long as we dont make user space to now start learning how to play acrobatics. cheers, jamal
