netdev - Re: [PATCH v3 net-next 7/8] ionic: add support for device id 0x1004

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 for Android: free password hash cracker in your pocket

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

Message-ID: <d9df0828-91d6-9089-e1b4-d82c6479d44c@pensando.io>
Date:   Thu, 5 Mar 2020 16:41:48 -0800
From:   Shannon Nelson <snelson@...sando.io>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH v3 net-next 7/8] ionic: add support for device id 0x1004

On 3/5/20 2:03 PM, Jakub Kicinski wrote:
> On Wed,  4 Mar 2020 21:23:18 -0800 Shannon Nelson wrote:
>> Add support for an additional device id.
>>
>> Signed-off-by: Shannon Nelson <snelson@...sando.io>
> I have thought about this for a while and I wanted to ask you to say
> a bit more about the use of the management device.
>
> Obviously this is not just "additional device id" in the traditional
> sense where device IDs differentiate HW SKUs or revisions. This is the
> same exact hardware, just a different local feature (as proven by the
> fact that you make 0 functional changes).
>
> In the past we (I?) rejected such extensions upstream from Netronome and
> Cavium, because there were no clear use cases which can't be solved by
> extending standard kernel APIs. Do you have any?

Do you by chance have any references handy to such past discussions?  
I'd be interested in reading them to see what similarities and 
differences we have.

The network device we present is only a portion of the DSC's functions.  
The device configuration and management for the various services is 
handled in userspace programs on the OS running inside the device.  
These are accessed through a secured REST API, typically through the 
external management ethernet port.  In addition to our centralized 
management user interface, we have a command line tool for managing the 
device configuration using that same REST interface.

In some configurations we make it possible to open a network connection 
into the device through the host PCI, just as if you were to connect 
through the external mgmt port.  This is the PCI deviceid that 
corresponds to that port, and allows use of the command line tool on the 
host.

The host network driver doesn't have access to the device management 
commands, it only can configure the NIC portion for what it needs for 
passing network packets.

sln

>
>> diff --git a/drivers/net/ethernet/pensando/ionic/ionic.h b/drivers/net/ethernet/pensando/ionic/ionic.h
>> index bb106a32f416..c8ff33da243a 100644
>> --- a/drivers/net/ethernet/pensando/ionic/ionic.h
>> +++ b/drivers/net/ethernet/pensando/ionic/ionic.h
>> @@ -18,6 +18,7 @@ struct ionic_lif;
>>   
>>   #define PCI_DEVICE_ID_PENSANDO_IONIC_ETH_PF	0x1002
>>   #define PCI_DEVICE_ID_PENSANDO_IONIC_ETH_VF	0x1003
>> +#define PCI_DEVICE_ID_PENSANDO_IONIC_ETH_MGMT	0x1004
>>   
>>   #define DEVCMD_TIMEOUT  10
>>   
>> diff --git a/drivers/net/ethernet/pensando/ionic/ionic_bus_pci.c b/drivers/net/ethernet/pensando/ionic/ionic_bus_pci.c
>> index 59b0091146e6..3dc985cae391 100644
>> --- a/drivers/net/ethernet/pensando/ionic/ionic_bus_pci.c
>> +++ b/drivers/net/ethernet/pensando/ionic/ionic_bus_pci.c
>> @@ -15,6 +15,7 @@
>>   static const struct pci_device_id ionic_id_table[] = {
>>   	{ PCI_VDEVICE(PENSANDO, PCI_DEVICE_ID_PENSANDO_IONIC_ETH_PF) },
>>   	{ PCI_VDEVICE(PENSANDO, PCI_DEVICE_ID_PENSANDO_IONIC_ETH_VF) },
>> +	{ PCI_VDEVICE(PENSANDO, PCI_DEVICE_ID_PENSANDO_IONIC_ETH_MGMT) },
>>   	{ 0, }	/* end of table */
>>   };
>>   MODULE_DEVICE_TABLE(pci, ionic_id_table);