Wed, Feb 17, 2016 at 12:17:26PM CET, j...@mojatatu.com wrote: >On 16-02-17 12:18 AM, John Fastabend wrote: >>This adds initial support for offloading the u32 tc classifier. This >>initial implementation only implements a few base matches and actions >>to illustrate the use of the infrastructure patches. >> >>However it is an interesting subset because it handles the u32 next >>hdr logic to correctly map tcp packets from ip headers using the ihl >>and protocol fields. After this is accepted we can extend the match >>and action fields easily by updating the model header file. >> >>Also only the drop action is supported initially. >> >>Here is a short test script, >> >> #tc qdisc add dev eth4 ingress >> #tc filter add dev eth4 parent ffff: protocol ip \ >> u32 ht 800: order 1 \ >> match ip dst 15.0.0.1/32 match ip src 15.0.0.2/32 action drop >> > >Note: i dont see anything that says "hw". Are you delegating ht 0x800 >for h/w only? It is the default ht; so may not be the best choice.
That is not implemented in this patchset. hw/sw/hwsw flag will be done in a follow up. So far, the user has only possibility to enable/disable the whole thing by ethtool feature flag. > >><-- hardware has dst/src ip match rule installed --> >> >> #tc filter del dev eth4 parent ffff: prio 49152 > >Would be useful to dump the installed rule so user gets to >see kernel-assigned prio 49152. The better way >to do this is use the handle 800::1 as opposed to prio. > >> #tc filter add dev eth4 parent ffff: protocol ip prio 99 \ >> handle 1: u32 divisor 1 >> #tc filter add dev eth4 protocol ip parent ffff: prio 99 \ >> u32 ht 800: order 1 link 1: \ >> offset at 0 mask 0f00 shift 6 plus 0 eat match ip protocol 6 ff >> #tc filter add dev eth4 parent ffff: protocol ip \ >> u32 ht 1: order 3 match tcp src 23 ffff action drop >> >><-- hardware has tcp src port rule installed --> >> >> #tc qdisc del dev eth4 parent ffff: >> >><-- hardware cleaned up --> >> > >All looks cool but I am just worried about the lack of intent that >something needs to go to hw vs sw. Other worry: >What happens when things fail to install in hw? Silently fail. I believe that this should be handled in the same follow-up I referred to above. >As it stands right now your assumption is all default rules go to h/w. >And failure to install is not handled. >I know Dave wants to push this in so a followup sets of patches to >address this is fine by me. Otherwise if it is not too much work, please >address this. > >cheers, >jamal
