mbox series

[v2,net-next,0/2] net: dsa: mv88e6xxx: LAG fixes

Message ID 20210115125259.22542-1-tobias@waldekranz.com (mailing list archive)
Headers show
Series net: dsa: mv88e6xxx: LAG fixes | expand

Message

Tobias Waldekranz Jan. 15, 2021, 12:52 p.m. UTC
The kernel test robot kindly pointed out that Global 2 support in
mv88e6xxx is optional.

This also made me realize that we should verify that the hardware
actually supports LAG offloading before trying to configure it.

v1 -> v2:
- Do not allocate LAG ID mappings on unsupported hardware (Vladimir).
- Simplify _has_lag predicate (Vladimir).

Tobias Waldekranz (2):
  net: dsa: mv88e6xxx: Provide dummy implementations for trunk setters
  net: dsa: mv88e6xxx: Only allow LAG offload on supported hardware

 drivers/net/dsa/mv88e6xxx/chip.c    |  6 +++++-
 drivers/net/dsa/mv88e6xxx/chip.h    |  5 +++++
 drivers/net/dsa/mv88e6xxx/global2.h | 12 ++++++++++++
 3 files changed, 22 insertions(+), 1 deletion(-)

Comments

Jakub Kicinski Jan. 15, 2021, 11:02 p.m. UTC | #1
On Fri, 15 Jan 2021 13:52:57 +0100 Tobias Waldekranz wrote:
> The kernel test robot kindly pointed out that Global 2 support in
> mv88e6xxx is optional.
> 
> This also made me realize that we should verify that the hardware
> actually supports LAG offloading before trying to configure it.
> 
> v1 -> v2:
> - Do not allocate LAG ID mappings on unsupported hardware (Vladimir).
> - Simplify _has_lag predicate (Vladimir).

If I'm reading the discussion on v1 right there will be a v3,
LMK if I got it wrong.
Vladimir Oltean Jan. 15, 2021, 11:24 p.m. UTC | #2
On Fri, Jan 15, 2021 at 03:02:46PM -0800, Jakub Kicinski wrote:
> On Fri, 15 Jan 2021 13:52:57 +0100 Tobias Waldekranz wrote:
> > The kernel test robot kindly pointed out that Global 2 support in
> > mv88e6xxx is optional.
> > 
> > This also made me realize that we should verify that the hardware
> > actually supports LAG offloading before trying to configure it.
> > 
> > v1 -> v2:
> > - Do not allocate LAG ID mappings on unsupported hardware (Vladimir).
> > - Simplify _has_lag predicate (Vladimir).
> 
> If I'm reading the discussion on v1 right there will be a v3,
> LMK if I got it wrong.

I don't think a v3 was supposed to be coming, what made you think that?
Jakub Kicinski Jan. 15, 2021, 11:46 p.m. UTC | #3
On Sat, 16 Jan 2021 01:24:35 +0200 Vladimir Oltean wrote:
> On Fri, Jan 15, 2021 at 03:02:46PM -0800, Jakub Kicinski wrote:
> > On Fri, 15 Jan 2021 13:52:57 +0100 Tobias Waldekranz wrote:  
> > > The kernel test robot kindly pointed out that Global 2 support in
> > > mv88e6xxx is optional.
> > > 
> > > This also made me realize that we should verify that the hardware
> > > actually supports LAG offloading before trying to configure it.
> > > 
> > > v1 -> v2:
> > > - Do not allocate LAG ID mappings on unsupported hardware (Vladimir).
> > > - Simplify _has_lag predicate (Vladimir).  
> > 
> > If I'm reading the discussion on v1 right there will be a v3,
> > LMK if I got it wrong.  
> 
> I don't think a v3 was supposed to be coming, what made you think that?

I thought you concluded that the entire CONFIG_NET_DSA_MV88E6XXX_GLOBAL2
should go, you said:

> So, roughly, you save 10%/13k. That hardly justifies the complexity IMO.
Vladimir Oltean Jan. 15, 2021, 11:55 p.m. UTC | #4
On Fri, Jan 15, 2021 at 03:46:22PM -0800, Jakub Kicinski wrote:
> On Sat, 16 Jan 2021 01:24:35 +0200 Vladimir Oltean wrote:
> > On Fri, Jan 15, 2021 at 03:02:46PM -0800, Jakub Kicinski wrote:
> > > On Fri, 15 Jan 2021 13:52:57 +0100 Tobias Waldekranz wrote:
> > > > The kernel test robot kindly pointed out that Global 2 support in
> > > > mv88e6xxx is optional.
> > > >
> > > > This also made me realize that we should verify that the hardware
> > > > actually supports LAG offloading before trying to configure it.
> > > >
> > > > v1 -> v2:
> > > > - Do not allocate LAG ID mappings on unsupported hardware (Vladimir).
> > > > - Simplify _has_lag predicate (Vladimir).
> > >
> > > If I'm reading the discussion on v1 right there will be a v3,
> > > LMK if I got it wrong.
> >
> > I don't think a v3 was supposed to be coming, what made you think that?
>
> I thought you concluded that the entire CONFIG_NET_DSA_MV88E6XXX_GLOBAL2
> should go, you said:
>
> > So, roughly, you save 10%/13k. That hardly justifies the complexity IMO.

That would be the first time that I hear of fixing a build failure due
to a missing shim by refactoring a driver... Punctual issue, punctual
fix, no?
Tobias Waldekranz Jan. 16, 2021, 12:12 a.m. UTC | #5
On Fri, Jan 15, 2021 at 15:46, Jakub Kicinski <kuba@kernel.org> wrote:
> On Sat, 16 Jan 2021 01:24:35 +0200 Vladimir Oltean wrote:
>> On Fri, Jan 15, 2021 at 03:02:46PM -0800, Jakub Kicinski wrote:
>> > On Fri, 15 Jan 2021 13:52:57 +0100 Tobias Waldekranz wrote:  
>> > > The kernel test robot kindly pointed out that Global 2 support in
>> > > mv88e6xxx is optional.
>> > > 
>> > > This also made me realize that we should verify that the hardware
>> > > actually supports LAG offloading before trying to configure it.
>> > > 
>> > > v1 -> v2:
>> > > - Do not allocate LAG ID mappings on unsupported hardware (Vladimir).
>> > > - Simplify _has_lag predicate (Vladimir).  
>> > 
>> > If I'm reading the discussion on v1 right there will be a v3,
>> > LMK if I got it wrong.  
>> 
>> I don't think a v3 was supposed to be coming, what made you think that?
>
> I thought you concluded that the entire CONFIG_NET_DSA_MV88E6XXX_GLOBAL2
> should go, you said:
>
>> So, roughly, you save 10%/13k. That hardly justifies the complexity IMO.

Well, based on what Andrew said, my guess is that that is where we will
end up.

But since at the moment net-next does not build for configs without
Global2-support, I would really appreciate it if this series could be
applied to solve that immediate problem.
Jakub Kicinski Jan. 16, 2021, 12:13 a.m. UTC | #6
On Sat, 16 Jan 2021 01:55:47 +0200 Vladimir Oltean wrote:
> On Fri, Jan 15, 2021 at 03:46:22PM -0800, Jakub Kicinski wrote:
> > On Sat, 16 Jan 2021 01:24:35 +0200 Vladimir Oltean wrote:  
> > > On Fri, Jan 15, 2021 at 03:02:46PM -0800, Jakub Kicinski wrote:  
> > > > On Fri, 15 Jan 2021 13:52:57 +0100 Tobias Waldekranz wrote:  
> > > > > The kernel test robot kindly pointed out that Global 2 support in
> > > > > mv88e6xxx is optional.
> > > > >
> > > > > This also made me realize that we should verify that the hardware
> > > > > actually supports LAG offloading before trying to configure it.
> > > > >
> > > > > v1 -> v2:
> > > > > - Do not allocate LAG ID mappings on unsupported hardware (Vladimir).
> > > > > - Simplify _has_lag predicate (Vladimir).  
> > > >
> > > > If I'm reading the discussion on v1 right there will be a v3,
> > > > LMK if I got it wrong.  
> > >
> > > I don't think a v3 was supposed to be coming, what made you think that?  
> >
> > I thought you concluded that the entire CONFIG_NET_DSA_MV88E6XXX_GLOBAL2
> > should go, you said:
> >  
> > > So, roughly, you save 10%/13k. That hardly justifies the complexity IMO.  
> 
> That would be the first time that I hear of fixing a build failure due
> to a missing shim by refactoring a driver... Punctual issue, punctual
> fix, no?

Sure, without knowing the driver it's hard to tell if it's a matter of
removing those stubs in the header, or more work, hence the question. 

Applied now, thanks!