On Wed, Apr 26, 2017 at 08:19:04AM +0200, Jiri Pirko wrote: > Tue, Apr 25, 2017 at 10:29:40PM CEST, j...@mojatatu.com wrote:
... > >So lets in first kernel I have support for bit 0. > >My validation check is to make sure only bit 0 is set. > >The valid_flags currently then only constitutes bit 0. > >i.e > >If you set bit 2 or 3, the function above will reject and i return > >the error to the user. > > > >That is expected behavior correct? > > > >3 months down the road: > >I add two flags - bit 1 and 2. > >So now my valid_flags changes to bits 1, 2 and 0. > > > >The function above will now return true for bits 0-2 but > >will reject if you set bit 3. > > > >That is expected behavior, correct? > > The same app compiled against new kernel with bits (0, 1, 2) will run with > this kernel good. But if you run it with older kernel, the kernel (0) > would refuse. Is that ok? Conversely, if an app is compiled against a new kernel and uses ATTR0, ATTR1 and ATTR2 all will be well. But if you run it against the older kernel ATTR1 and ATTR2 will be silently ignored. I believe that is how its always been but is that ok? > >On u32/16/8: > >I am choosing u32 so it allows me to add more upto 32 bit flags. > >Not all 32 are needed today but it is better insurance. > >If I used u8 then the 24 of those 32 bits i dont use will be used > >as pads in the TLV. So it doesnt make sense for me to use a u8/16. > > Jamal, note that I never suggested having more flags in a single attr. > Therefore I suggested u8 to carry a single flag. > > You say that it has performance impact having 3 flag attrs in compare to > one bit flag attr. Could you please provide some numbers? > > I expect that you will not be able to show the difference. And if there > is no difference in performance, your main argument goes away. And we > can do this in a nice, clear, TLV fashion.
