From: Samuel Mendoza-Jonas <sam@mendozajonas.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [PATCH net] net/ncsi: Don't assume last available channel exists
Date: Wed, 27 Sep 2017 14:12:40 +1000 [thread overview]
Message-ID: <1506485560.1757.16.camel@mendozajonas.com> (raw)
In-Reply-To: <20170921.181111.2086501653519863373.davem@davemloft.net>
On Thu, 2017-09-21 at 18:11 -0700, David Miller wrote:
> From: Samuel Mendoza-Jonas <sam@mendozajonas.com>
> Date: Fri, 22 Sep 2017 11:00:00 +1000
>
> > If we haven't configured a channel yet (or are in the process of doing
> > so) we won't have a hot_channel - does it make more sense to
> > - check against the hot_channel as currently done,
> > - only check the filter size at configure time for /each/ channel,
> > - only conditionally enable the .ndo_vlan_rx_add_vid net_device callback
> > once we've configured a channel (eg. for ftgmac100 in the
> > ftgmac100_ncsi_handler() callback?)
>
> The last isn't so feasible.
>
> The device shouldn't be marked attached until a channel is available,
> because it seems like communication cannot occur until one is. Right?
Yes that's right.
>
> You could experiment with netif_device_detach()/netif_device_attach().
>
> When the device is in the detached state, callbacks such as
> ->ndo_vlan_rx_add_vid() will not be invoked.
This looked like the way at first, but _detach() ceases any tx/rx on the
interface right?
NCSI still needs the interface to be active since the 'channels' are on a
separate network controller that the interface is connected to, eg on the
machines I'm using:
BMC 'Host' network controller
---------------------- ----------------------------
|ftgmac100 interface | <---- NCSI Link ----> | BCM5719 interface | --> external interface
---------------------- ----------------------------
Looking at the NCSI init path I believe we're guaranteed to have an ndp
struct by the time ndo_vlan_rx_add_vid() is called, making some of those
checks overly cautious. It might be easiest to just track new vids as we
see them (up to the NCSI spec limit), and then deal with configured
channels on a case by case basis since their limits can be different.
I'll work on a V2 but hopefully I haven't misinterpreted
_detach()/_attach() :)
Sam
prev parent reply other threads:[~2017-09-27 4:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-20 4:12 Samuel Mendoza-Jonas
2017-09-20 23:05 ` David Miller
2017-09-22 1:00 ` Samuel Mendoza-Jonas
2017-09-22 1:11 ` David Miller
2017-09-27 4:12 ` Samuel Mendoza-Jonas [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1506485560.1757.16.camel@mendozajonas.com \
--to=sam@mendozajonas.com \
--cc=benh@kernel.crashing.org \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®