On Mon, 29 Aug 2016 23:09:35 +0200, Daniel Borkmann wrote: > > + * 0,1 ok NOT SUPPORTED[1] > > + * 2 drop 0x22 -> drop, count as stat1 > > + * 4,5 nuke 0x02 -> drop > > + * 7 redir 0x44 -> redir, count as stat2 > > + * * unspec 0x11 -> pass, count as stat0 > > + * > > + * [1] We can't support OK and RECLASSIFY because we can't tell TC > > + * the exact decision made. We are forced to support UNSPEC > > + * to handle aborts so that's the only one we handle for passing > > + * packets up the stack. > > In da mode, RECLASSIFY is not supported, so this one could be scratched. > For the OK and UNSPEC part, couldn't both be treated the same (as in: OK / > pass to stack roughly equivalent as in sch_handle_ingress())? Or is the > issue that you cannot populate skb->tc_index when passing to stack (maybe > just fine to leave it at 0 for now)?
The comment is a bit confus(ed|ing). The problem is: tc filter add <filter1> skip_sw tc filter add <filter2> skip_hw If packet appears in the stack - was it because of OK or UNSPEC (or RECLASSIFY) in filter1? Do we need to run filter2 or not? Passing tc_index can be implemented the same way I do mark today. > Just curious, does TC_ACT_REDIRECT work in this scenario? I do the redirects in the card, all the problems stem from the difficulty of passing full ret code in the skb from the driver to tc_classify()/cls_bpf_classify().
