On Mon, Apr 24, 2017 at 08:49:00AM -0400, Jamal Hadi Salim wrote: > 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.
jamal, what performance concern you have in building this error message? TLVs is the most flexible way. And this is error path, so we should build this message rarely, only if the user sends us something incorrect, why bother...
