On Fri, 26 Apr 2019 20:41:45 +0200, Pablo Neira Ayuso wrote: > > > > >Hence, this emulates the shared blocks available in TC that Jiri made. > > > > > > > > > >Note that the list of tcf_block_cb objects will be called to offload > > > > >policies in this chain. > > > > > > > > So you are going to use chain_id (if there is anything like that) as > > > > block_index during offload, right? > > > > > > Yes. But I don't need to expose this chain_index to userspace though, > > > I can internally allocate it, I only need to make sure it does not > > > overlap with any of the existing tc block_indexed. I can just use a > > > different index space which does not overlap with the tc block index > > > space. > > > > How will the association between a block and a device work for > > netfilter? > > My proposal is that Netfilter doesn't need to expose anything similar > to the TC block concept. I mean, not to the user, not through the > command line and netlink itself. Yes, yes. > If netfilter supports for chain definitions like this: > > table x { > chain y { > type filter hook ingress devices = { eth0, eth1 } priority 0; > } > } > > Then the chain 'y' implicitly becomes the block for the 'eth0' and > 'eth1' devices. Can there be more chains for those devices? Or those will only run y from netfilter perspective? > Note that the above is not yet supported, I need to extend the netlink > API for this, but having chains that are attached to multiple devices > is feasible and it makes sense for plain software configurations where > no offload is involved (as useful as the TC block for pure software to > avoid policy duplication).