Out-of-band NIC management

[Justin.Lee1 at Dell.com]

> > Hi Ben,
> >
> > I have a few questions about the 2.c item below.
> >
> >
> > > For the CLI tool and management & monitoring daemon, I was initially thinking using NC-SI over RMII/RBT, mainly because kernel already supports this and it provides a netlink interface for userspace to send/receive commands.
> > > But I think we can make our management tool transportation agnostic, so for NCSIoRMII/RBT, it communicates to kernel NCSI driver over netlink, and for NCSI over MCTP, it uses a the mechanism provided by libmctp.
> > > 
> > > > > And in kernel 5.x , NC-SI driver supports Netlink interface for 
> > > > > communicating with userspace processes.
> > > > >   
> > > > > I'm thinking adding the following tools to OpenBMC as a starting 
> > > > > point and build form there:
> > > > >  
> > > > >       1. A command line utility (e.g. ncsi-util) to send raw 
> > > > > NC-SI commands, useful for debugging and initial NIC bring up,
> > > > >       For example:
> > > > >           ncsi-util -eth0 -ch 0 <raw NC-SI command>
> > > > >  
> > > > >       We can further extend this command line tool to support 
> > > > > other management interfaces, e.g sending MCTP or PLDM commands to NIC.
> > > > >  
> > > > >       2. A daemon running on OpenBMC (e.g ncsid) monitoring NIC 
> > > > > status,  for example:
> > > > >           a. Query and log NIC capability and current parameter 
> > > > > setting
> > > > >           b. Periodically check NIC link status, re-initialize 
> > > > > NC-SI link if NIC is unreachable, log the status
> > > > >           c. Enable and monitor NIC Asynchronous Event 
> > > > > Notifications
> > > > > (AENs)
> >
> >
> > For selected channels, AEN is enabled by default. Do you plan to enable the AEN for non-selected channels too?
> > If yes, what is the approach you are going to do? Enable it by userspace or modify NC-SI driver to achieve that?
> > We are planning to monitor all channels but still look for the best way.
> >
> 
> Hi Justin,
> For now I only plan to monitor selected channel. But I'm curious about the AEN enabled by default. Is this performed by kernel driver today?
> In the previous version (e.g. 4.x), I had to manually enable  (or subscribe to) them after NC-SI initialization.


Hi Ben,

Inside the ncsi_configure_channel() function, there is one state to enable the AEN (unless the capability bit for AEN is not set).

		} else if (nd->state == ncsi_dev_state_config_ae) {
			nca.type = NCSI_PKT_CMD_AE;
			nca.bytes[0] = 0;
			nca.dwords[1] = nc->caps[NCSI_CAP_AEN].cap;


> 
> (this is why I was thinking a userspace CLI to check NIC parameters would be useful to get the current NIC setting)
> 
> But in any case (selected vs all channels), I am thinking having some tool or daemon in userspace to modify AEN setting would provide flexibility, since kernel driver already provides access mechanism.
> For the 2.c case, we may selectively enable AENs based on "get capability" cmd. Also we may check which OEM AENs (if any) are supported, and based on our needs selectively enable/disable these.
> 
> 
> > For delivering the AEN to userspace, currently, we implement it via the mcgrps locally but plan to upstream.
> >
> > enum ncsi_genl_multicast_groups {
> >	NCSI_GENL_MCGRP_AEN,
> > };
> >
> > static const struct genl_multicast_group ncsi_genl_mcgrps[] = {
> >	[NCSI_GENL_MCGRP_AEN] = { .name = NCSI_GENL_MCGRP_AEN_NAME }, };
> >
> > static struct genl_family ncsi_genl_family __ro_after_init = {
> >	.name = "NCSI",
> >	.version = 0,
> >	.maxattr = NCSI_ATTR_MAX,
> >	.module = THIS_MODULE,
> >	.ops = ncsi_ops,
> >	.n_ops = ARRAY_SIZE(ncsi_ops),
> >	.mcgrps = ncsi_genl_mcgrps,
> >	.n_mcgrps = ARRAY_SIZE(ncsi_genl_mcgrps), };
> >
> >
> 
> This is a great idea! Previously I had a hacky solution to send a custom netlink message for AENs, but this multicast group is more flexible.
> In your current design, do you have multiple processes listening to these? Or 1 process that handles all AENs.


Currently, we will only have one process to listen all AENs but it is not finalized yet.


> 
> Regards,
> -Ben
> 

Thanks,
Justin