[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180921084634.222aaf93@cakuba.netronome.com>
Date: Fri, 21 Sep 2018 08:46:34 -0700
From: Jakub Kicinski <jakub.kicinski@...ronome.com>
To: Arjun Vynipadath <arjun@...lsio.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net, dt@...lsio.com,
nirranjan@...lsio.com, indranil@...lsio.com,
Casey Leedom <leedom@...lsio.com>,
Ganesh Goudar <ganeshgr@...lsio.com>
Subject: Re: [PATCH net-next] cxgb4vf: Add ethtool private flags for
changing force_link_up
On Fri, 21 Sep 2018 16:16:31 +0530, Arjun Vynipadath wrote:
> On Tuesday, September 09/18/18, 2018 at 11:39:14 -0700, Jakub Kicinski wrote:
> > On Tue, 18 Sep 2018 18:37:23 +0530, Arjun Vynipadath wrote:
> > > Forcing link up of virtual interfaces even when physical link is down
> > > causes packet drops and ping failures during bonding failover. Hence
> > > adding a ethtool private flag to toggle force_link_up whenever required.
> > >
> > > Signed-off-by: Arjun Vynipadath <arjun@...lsio.com>
> > > Signed-off-by: Casey Leedom <leedom@...lsio.com>
> > > Signed-off-by: Ganesh Goudar <ganeshgr@...lsio.com>
> >
> > Could you describe how this mechanism relates to the existing
> > ndo_set_vf_link_state, which you seem to not make use of:
> >
> > $ git grep ndo_set_vf_link_state -- drivers/net/ethernet/chelsio/
> > $
> >
> > I understand you're configuring the setting from the VF side, but the
> > question, as always, is: why ;)
> Hi Jakub,
> ndo_set_vf_link_state can't be presently used in our case.
> We dont have firmware support to communicate the link flags set through
> ndo_set_vf_link_state from pf (cxgb4) driver to vf (cxgb4vf) driver.
FW is just SW that runs on a card :) Is that a HW limitation?
What I was thinking after a quick look at the code was this:
- add a new bit to GET_PORT_INFO to indicate that the VF driver should
brink the link state up/down wtih netif_carrier_off()/
netif_carrier_on();
- in FW set this bit based on the ndo_set_vf_link_state policy and
link state.
But you're saying that extending GET_PORT_INFO or communicating this
info in other ways is not an option? It would be nice to stick to the
existing kernel APIs, if they address exactly the kind of configuration
you're trying to perform.
Powered by blists - more mailing lists