> -----Original Message----- > From: [email protected] [mailto:fcoe-devel- > [email protected]] On Behalf Of Mike Christie > Sent: Friday, September 05, 2014 10:15 AM > To: Neil Horman; Chad Dupuis > Cc: [email protected] > Subject: Re: [Open-FCoE] Adding FIP VLAN functions to libfcoe > > 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.
What DCB info you are looking through the translation ? The fcoe works on a netdev and same netdev to have its DCB info passed up as currently done by ixgbe/i40e to tag fcoe priority correctly. Creating another cna_device and then link to netdev is like converging on top while these could be from two different PF of a MFP device and that shouldn't be required for any DCB info. > Storage drivers would interact translate between the > cna_device and their scsi_host/fc_host/iscsi_host/pci_device. > A can_device would not serve any additional purpose which could not be done by netdev as I explained above in regard to pulling DCB info. > 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. > User tools are built around netdev to create and manage fcoe instance on them, and adding dummy netdev will be least disruptive while exposing complete port capabilities to netdev subsystem instead partly CNA port directly hooked up to the storage stack. Thanks, Vasu > _______________________________________________ > fcoe-devel mailing list > [email protected] > http://lists.open-fcoe.org/mailman/listinfo/fcoe-devel _______________________________________________ fcoe-devel mailing list [email protected] http://lists.open-fcoe.org/mailman/listinfo/fcoe-devel
