netdev - Re: [PATCH net-next 00/10] NCSI Support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1467754959.13965.66.camel@kernel.crashing.org>
Date:	Wed, 06 Jul 2016 07:42:39 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Alexei Starovoitov <alexei.starovoitov@...il.com>,
	Or Gerlitz <gerlitz.or@...il.com>
Cc:	Gavin Shan <gwshan@...ux.vnet.ibm.com>,
	Linux Netdev List <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>, joel@....id.au,
	weixue@...stnetic.com, yuvali@...lanox.com
Subject: Re: [PATCH net-next 00/10] NCSI Support

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.

> > >    * The first NIC driver that is aware of NCSI: drivers/net/ethernet/faraday/ftgmac100.c
> > 
> > 
> > FWIW, talking to a colleague, he made a comment that some of the text
> > above is wrong:
> > 
> > AENs are sent from NIC to BMC. Not from Host to BMC.
> > 
> > The traffic between a BMC and a NIC is over RBT if it is formatted as
> > NC-SI packets. This is not over network traffic....
> > 
> > Or.
> 
> Or,
> since cx4 has ncsi as well, could you do a thorough review of this
> to make sure that it fits mellanox nics as well?

Cheers,
Ben.