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).
