Re: [RFC PATCH nft 0/6] flow statement

[Patrick McHardy <kaber@trash.net>]

On 10.11, Pablo Neira Ayuso wrote:
> Hi Patrick,
> 
> On Fri, Nov 06, 2015 at 06:34:17PM +0000, Patrick McHardy wrote:
> > The following patches add support for the flow statement, which allows to
> > dynamically instantiate stateful statements fow an arbitrary defined flow
> > key.
> >
> > Currently we have to stateful statements, counter and limit. This example
> > shows some accounting possibilities using the counter statement. Please note
> > that the output format is still WIP and not included in this patchset:
> >
> > # nft filter input flow table test iif . tcp flags counter
> 
> This looks very good to me :-).
> 
> > # nft list flow table filter test
> > iface_index	tcp_flag	statement
> > lo		fin | psh | urg	counter packets 1002 bytes 40080
> > wlp2s0		fin | ack	counter packets 3 bytes 156
> > wlp2s0		ack		counter packets 32 bytes 18440
> > wlp2s0		syn | ack 	counter packets 5 bytes 300
> > wlp2s0		psh | ack	counter packets 57 bytes 13804
> > lo		rst | ack	counter packets 998 bytes 39920
> > 
> > # nft filter output flow table uidacct skuid . oif . ip protocol counter
> > # nft list flow table filter uidacct
> 
> BTW, I can see the content is currently listed (in the non-pretty
> output format) through:
> 
>         nft list set filter test
> 
> so I can see how that flow table gets populated with entries.

Yes, for now this is not explicitly surpressed.

> >From the syntax perspective, I'm aware this the general definition in
> the industry for this is 'flow table' but my only concern here with
> this denomination is that we already have in our own tables with quite
> different semantics.

You mean our rule tables? Yeah, but this is explicitly qualified as
"flow" table. I don't really think there is much room for confusion.

I'm open to suggestions of course.

> Moreover, the fact that we can list this as sets (since they are
> actually using the generic nf_tables set infrastructure) may be
> confusing to users.

That is only until we have explicit listing for these. I'll hide them
from the set view then.

> BTW, should we have implicit and explicit flow tables just like sets?

So far explicit flow tables don't make sense since the kernel enforces
that only a single binding exists. I've added this since the desired
semantics of shared flow tables have to be hashed out first and I didn't
want to commit to something without thinking it through.