On Tue, Dec 11, 2018 at 9:15 PM David Miller <da...@davemloft.net> wrote: > From: Florian Westphal <f...@strlen.de> > > Pablo Neira Ayuso <pa...@netfilter.org> wrote: > >> This is another iteration of the in-kernel intermediate representation > >> (IR) that allows to express ACL hardware offloads using one unified > >> representation from the driver side for the ethtool and the tc > >> frontends [1] [2] [3].
> > This is marked 'rejected' in patchwork, what happened? > Pablo is not being honest about his true intentions and long term > goals with this series. Or also brought up fundamental objections > against previous versions of this series which were not sufficiently > addressed by Pablo. H Dave, To put it a bit more clearly, donno if my concerns are to the extent of being fundamental, but yesknow that they were not sufficiently addressed. TC is the leading kernel CA system for about 2.5 decades, so I am not clear what we want to IR the TC offload path and not TCfy the ethtool and Co offloads path. 9 Going forward to 2019 HWs that can offload OVS/OF (flow) metering, do we really want to IR the TC policers which follow IEEE or a like specs? Still, seems that other folks on the drivers yard are ok and even happy with the IR direction/implementation, I see that Jiri acked it all. I guess we need some voices to speak, would love to hear the whole of the CCed JJJ triplet speaking up. > My personal concern has been brought up several times. I will go dig for it, that's ineed hard when concerns are not replied :( > I am not going to restate the same thing over and over, and he hasn't > fixed up his introductory posting in response to my concerns in any > meaningful and full way. > > Therefore, if I feel like my and Or's feedback will keep being > ignored, I will keep rejecting these changes.
