On Thu, Oct 17, 2019 at 06:11:57PM +0200, Pablo Neira Ayuso wrote: [...] > > (3) it causes loss of functionality (looks like a single u32 changing > > both sport and dport is rejected by the IR since it wouldn't > > match fields); > > Not correct. > > tc filter add dev eth0 protocol ip \ > parent ffff: \ > pref 11 \ > flower ip_proto tcp \ > dst_port 80 \ > src_ip 1.1.2.3/24 \ > action pedit ex munge tcp src 2004 \ > action pedit ex munge tcp dst 80 > > This results in two independent tc pedit actions: > > * One tc pedit action with one single key, with value 0xd4070000 / > 0x0000ffff. > * Another tc pedit action with one single key, with value 0x00005000 > / 0xffff0000. > > This works perfectly with this patchset. You refer to single u32 word changing both sport and dport. What's the point with including this in the subset of the uAPI to be supported? In software, it really makes sense to use this representation since it is speeding up packet processing. In hardware, supporting this uAPI really gets you nothing at all. We have to document what subset of the uAPI is support through hardware offloads. Pretending that we can support all uAPI is not true, we only support for tc pedit extended mode right now.
