[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190902175526.72gsb4c4hoswd4ds@lx-anielsen.microsemi.net>
Date: Mon, 2 Sep 2019 19:55:27 +0200
From: "Allan W. Nielsen" <allan.nielsen@...rochip.com>
To: Andrew Lunn <andrew@...n.ch>
CC: Ido Schimmel <idosch@...sch.org>,
David Miller <davem@...emloft.net>, <jiri@...nulli.us>,
<horatiu.vultur@...rochip.com>, <alexandre.belloni@...tlin.com>,
<UNGLinuxDriver@...rochip.com>, <ivecera@...hat.com>,
<f.fainelli@...il.com>, <netdev@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 1/2] net: core: Notify on changes to dev->promiscuity.
The 09/01/2019 20:48, Andrew Lunn wrote:
> > Look, this again boils down to what promisc mode means with regards to
> > hardware offload. You want it to mean punt all traffic to the CPU? Fine.
> > Does not seem like anyone will be switching sides anyway, so lets move
> > forward. But the current approach is not good. Each driver needs to have
> > this special case logic and the semantics of promisc mode change not
> > only with regards to the value of the promisc counter, but also with
> > regards to the interface's uppers. This is highly fragile and confusing.
> Yes, i agree. We want one function, in the core, which handles all the
> different uppers. Maybe 2, if we need to consider L2 and L3 switches
> differently.
Are you suggesting that we continue the path in v3, but add a utility function
to determinate if the interface needs to go into promisc mode (taking the
bridge stats, the promisc counter, and the upper devices into account).
Or are you suggest that we like Ido go back to v2?
/Allan
Powered by blists - more mailing lists