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. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
