On 07/30/2014 10:20 AM, Neil Horman wrote: > On Wed, Jul 30, 2014 at 12:33:21PM +0000, Chad Dupuis wrote: >> Hi Folks, >> >> The current implementation of fcoe-utils is highly dependent on netlink >> sockets created on network interfaces for receiving netlink events and fc >> events. We have a new multi PCI function hardware architecture which may >> not expose L2 interface for storage enabled PCI functions. Due to this >> network socket dependency we will not be able to use current >> implementation of fcoe-utils. What we would like to do is add two library >> functions to libfcoe to be able to initiate a FIP VLAN request and parse >> the results to inform the LLD of the VLAN via a callback. >> >> More specifically, we would like to add a new exported function to >> libfcoe, fcoe_send_vlan_req() which would form the FIP frame and send it >> to the LLD using the fcoe_ctlr->send() callback. Then in fcoe_ctlr_recv(), >> we would add an additional check for the op FIP_OP_VLAN. If this check is >> true we would call another new function, fcoe_process_vlan_resp(), where >> we would extract the VLAN ID. We would also like to add a function >> callback to the fcoe_ctlr struct, update_vlan(uint16_t vlan), which a LLD >> could add a handler for to get notification of the VLAN from the FIP VLAN >> request. Moving this functionality into libfcoe would enable other low >> level drivers to take advantage of this functionality as well. >> >> Note that the implementation of fcoe_send_vlan_req() would be based on >> fnic_fcoe_send_vlan_req() and fcoe_process_vlan_resp() would be based on >> fnic_fcoe_process_vlan_resp(). >> >> We wanted to get community feedback on this before heading in this >> direction. >> > This seems a bit...insufficient in my mind, unless I'm missing something. > FCoE > being Fibre Channel over Ethernet somewhat by definition presupposes the > existance of an ethernet interface, and therefore the ability to interface to > that ethernet interface. While what you have above seems like it could be > used > to handle the data path for FCoE, it seems to ignore the other configuration > and control aspects of FCoE (how is lldpad/fcoemon in user space meant to > understand the > interface dcb state without a network interface to connect to, for instance). > > To play devils advocate a bit, it seems like your hardware could eaily > implement > a dummy net_device interface (see dummy.c for an example), that > created/registered a network interface, and did the datapath translation from > the net_device api to whatever interface the PCI storage function presented. >
iSCSI offload driver need something similar to hook into the dcb code. We have been looking into creating a new cna_device struct which the kernel dcb code would use. Driver like ixgbe/fcoe.ko would translate between that and net_devices. Storage drivers would interact translate between the cna_device and their scsi_host/fc_host/iscsi_host/pci_device. If doing the dummy net device is ok with the net people than that is easier. The problem with creating a new cna_device struct is the existing userspace tools look for the net_device so we either have to break userspace or do some compat code. _______________________________________________ fcoe-devel mailing list [email protected] http://lists.open-fcoe.org/mailman/listinfo/fcoe-devel
