lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 21 Nov 2020 19:56:21 +0100
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Tobias Waldekranz <tobias@...dekranz.com>,
        netfilter-devel@...r.kernel.org, davem@...emloft.net,
        netdev@...r.kernel.org, razor@...ckwall.org, jeremy@...zel.net
Subject: Re: [PATCH net-next,v3 0/9] netfilter: flowtable bridge and vlan
 enhancements

On Sat, Nov 21, 2020 at 10:15:51AM -0800, Jakub Kicinski wrote:
> On Sat, 21 Nov 2020 13:31:38 +0100 Pablo Neira Ayuso wrote:
> > On Mon, Nov 16, 2020 at 11:56:58PM +0100, Pablo Neira Ayuso wrote:
> > > On Mon, Nov 16, 2020 at 02:45:21PM -0800, Jakub Kicinski wrote:  
> > > > On Mon, 16 Nov 2020 23:36:15 +0100 Pablo Neira Ayuso wrote:  
[...]
> > I have been discussing the topology update by tracking fdb updates
> > with the bridge maintainer, I'll be exploring extensions to the
> > existing fdb_notify() infrastructure to deal with this scenario you
> > describe. On my side this topology update scenario is not a priority
> > to be supported in this patchset, but it's feasible to support it
> > later on.
> 
> My concern is that invalidation is _the_ hard part of creating caches.
> And I feel like merging this as is would be setting our standards pretty
> low. 

Interesting, let's summarize a bit to make sure we're on the same
page:

- This "cache" is optional, you enable it on demand through ruleset.
- This "cache" is configurable, you can specify through ruleset policy
  what policies get into the cache and _when_ they are placed in the
  cache.
- This is not affecting any existing default configuration, neither
  Linux networking not even classic path Netfilter configurations,
  it's a rather new thing.
- This is showing performance improvement of ~50% with a very simple
  testbed. With pktgen, back few years ago I was reaching x2.5
  performance boost in software in a pktgen testbed.
- This is adding minimal changes to netdev_ops, just a single
  callback.

For the live VM migration you describe, connections might time out,
but there are many use-cases where this is still valid, some of them
has been described already here.

> Please gather some review tags from senior netdev developers. I don't
> feel confident enough to apply this as 100% my own decision.

Fair enough.

This requirement for very specific Netfilter infrastructure which does
not affect any other Networking subsystem sounds new to me.

What senior developers specifically you would like I should poke to
get an acknowledgement on this to get this accepted of your
preference?

Thank you.

Powered by blists - more mailing lists