On 16-02-25 05:19 AM, Jamal Hadi Salim wrote: > On 16-02-24 11:09 PM, John Fastabend wrote: >> On 16-02-24 01:29 AM, Jiri Benc wrote: >>> On Wed, 24 Feb 2016 00:55:55 -0800, John Fastabend wrote: >>>> The flags however likely stays with with TCA_U32_FLAGS until there is >>>> some better way to group common attributes in 'tc' framework. >>> >>> That's pretty bad, as this is uAPI and will need to be supported >>> forever. And having a different attribute in every filter won't ease >>> things for user space tools. I'd say we need the "better way" to be >>> added before this patchset. >>> >>> Jiri >>> >> >> The 'tc' semantics seem to support this "pretty bad" API design >> with many of the fields already duplicated. > > Mostly this is a netlink-ism. Netlink has the same problem with > command name spaces. The problem is mixing verbs and nouns together. > I like the switchdev approach where you have very few verbs > (SET, GET etc) and the content of the object or path describes > the nouns. This is why initially i thought it was better to have > this offload passing by switchdev. Could we leverage some of that? >
No I don't think so. Either way you need some flag at the 'tc' layer to push this down to hardware offload ops. >> I suppose we could >> put the flags at the same level as the TCA_* attributes but this >> also doesn't seem right to me as it isn't actually handled until >> we get into the TCA_#CLASSIFIER#_* set of attributes. >> > > Could we not steal a couple of bits off netlink flags? Then it applies > to all subssystems. I did that in some original patch I never sent but I didn't like it. Netlink is used for all sorts of things and those flags already have a meaning. We've already started this trend of using flags inside the specific messages for other things like the bridge code. And there are only a few bits left in the rtnetlink flags field I would prefer to save them for something necessary. In the end I think the solution here is really not that bad the userspace code to add it is trivial (~5 lines of code). Its not how I would do it if I was writing the entire OS from scratch but we have to maintain UAPI so not sure I have any better solutions. > > cheers, > jamal >
