From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Or Gerlitz <gerlitz.or@gmail.com>,
Gavin Shan <gwshan@linux.vnet.ibm.com>,
Linux Netdev List <netdev@vger.kernel.org>,
David Miller <davem@davemloft.net>,
joel@jms.id.au, weixue@trustnetic.com, yuvali@mellanox.com
Subject: Re: [PATCH net-next 00/10] NCSI Support
Date: Tue, 5 Jul 2016 19:07:33 -0700 [thread overview]
Message-ID: <20160706020731.GA82573@ast-mbp> (raw)
In-Reply-To: <1467754959.13965.66.camel@kernel.crashing.org>
On Wed, Jul 06, 2016 at 07:42:39AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2016-07-05 at 10:44 -0700, Alexei Starovoitov wrote:
> >
>
> .../...
>
> > > > The design for the patchset is highlighted as below:
> > > >
> > > > * The NCSI interface is abstracted with "struct ncsi_dev". It's registered
> > > > when net_device is created, started to work by calling ncsi_start_dev()
> > > > when net_device is opened (ndo_open()). For the first time, NCSI packets
> > > > are sent and received to/from the far end (host in above figure) to probe
> > > > available NCSI packages and channels. After that, one channel is chosen as
> > > > active one to provide service.
> > > > * The NCSI stack is driven by workqueue and state machine internally.
> > > > * AEN (Asychronous Event Notification) might be received from the far end
> > > > (host). The currently active NCSI channel fails over to another available
> > > > one if possible. Otherwise, the NCSI channel is out of service.
> > > > * NCSI stack should be configurable through netlink or another mechanism,
> > > > but it's not implemented in this patchset. It's something TBD.
> >
> > Gavin,
> > what configurations do you have in mind?
> > For ncsi itself or to control the nic on the host?
> > This set of patches is for BMC side, right?
> > What needs to be done on the host?
>
> I'll respond for Gavin since I'm awake first ;-)
>
> We use that stack today on OpenBMC on some OpenPOWER machines.
>
> The configuration is thus for the above stack to run on the BMC in
> order to control the host NIC.
>
> NC-SI capable host NICs operate autonomously, so there is nothing to be
> done on the host OS itself, at least not with the BCM NICs that we use
> today, but of course the host NIC firmware needs to have the other side
> of the stack.
Great! Thanks for clarifying.
So then future netlink api is mandatory to drive this kernel patches?
How one can use this set without it?
What is the main reason for this infra to be in the kernel instead of
userspace raw socket? Some interaction with the driver, right?
but it's not obvious from the patches.
next prev parent reply other threads:[~2016-07-06 2:07 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-03 5:32 [PATCH net-next 00/10] NCSI Support Gavin Shan
2016-07-03 5:32 ` [PATCH net-next 01/10] net/ncsi: Resource management Gavin Shan
2016-07-03 5:32 ` [PATCH net-next 02/10] net/ncsi: NCSI command packet handler Gavin Shan
2016-07-03 5:32 ` [PATCH net-next 03/10] net/ncsi: NCSI response " Gavin Shan
2016-07-03 5:32 ` [PATCH net-next 04/10] net/ncsi: Package and channel management Gavin Shan
2016-07-03 5:32 ` [PATCH net-next 05/10] net/ncsi: NCSI AEN packet handler Gavin Shan
2016-07-03 5:32 ` [PATCH net-next 06/10] net/farady: Helper functions to create or destroy MDIO interface Gavin Shan
2016-07-03 5:32 ` [PATCH net-next 07/10] net/farady: Read MAC address from chip Gavin Shan
2016-07-03 5:32 ` [PATCH net-next 08/10] net/farady: Support NCSI mode Gavin Shan
2016-07-03 5:32 ` [PATCH net-next 09/10] net/farady: Match driver according to compatible property Gavin Shan
2016-07-03 5:32 ` [PATCH net-next 10/10] net/farady: Mask PHY interrupt with NCSI mode Gavin Shan
2016-07-03 22:03 ` [PATCH net-next 00/10] NCSI Support Or Gerlitz
2016-07-03 22:49 ` Benjamin Herrenschmidt
2016-07-04 0:24 ` Gavin Shan
2016-07-05 17:44 ` Alexei Starovoitov
2016-07-05 21:42 ` Benjamin Herrenschmidt
2016-07-06 2:07 ` Alexei Starovoitov [this message]
2016-07-06 2:14 ` Benjamin Herrenschmidt
2016-07-07 9:12 ` Or Gerlitz
2016-07-07 9:17 ` Benjamin Herrenschmidt
2016-07-07 9:18 ` Benjamin Herrenschmidt
2016-07-07 13:05 ` Gavin Shan
2016-07-07 13:44 ` Or Gerlitz
2016-07-07 16:34 ` Gavin Shan
2016-07-07 17:32 ` Florian Fainelli
2016-07-07 22:05 ` Benjamin Herrenschmidt
2016-07-08 1:10 ` Gavin Shan
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=20160706020731.GA82573@ast-mbp \
--to=alexei.starovoitov@gmail.com \
--cc=benh@kernel.crashing.org \
--cc=davem@davemloft.net \
--cc=gerlitz.or@gmail.com \
--cc=gwshan@linux.vnet.ibm.com \
--cc=joel@jms.id.au \
--cc=netdev@vger.kernel.org \
--cc=weixue@trustnetic.com \
--cc=yuvali@mellanox.com \
/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;
as well as URLs for NNTP newsgroup(s).