On 09/29/2009 05:25 PM, Joe Eykholt wrote: > Mike Christie wrote: >> On 09/29/2009 04:39 PM, Mike Christie wrote: >>> On 09/29/2009 04:21 PM, Mike Christie wrote: >>>> On 09/29/2009 04:19 PM, Mike Christie wrote: >>>>> On 09/29/2009 02:03 PM, Joe Eykholt wrote: >>>>>> Joe Eykholt wrote: >>>>>>> The kernel no longer has symlinks where libhbalinux expected them. >>>>>>> I'm not sure which kernel version this was written for. >>>>>>> >>>>>>> Don't expect "/sys/class/fc_hosts/<hostx>" to be a symlink. >>>>>>> Change to look for the symlink "/sys/class/fc_hosts/<hostx>/device". >>>>>>> >>>>>>> Don't expect the strings "/net/" or "/virtual/net/" to be in the >>>>>>> symlink. >>>>>>> >>>>>>> To find the real interface for a vlan, compare the iflink and >>>>>>> ifindex. >>>>>>> If they are not the same, look for the interface who's ifindex >>>>>>> matches >>>>>>> the iflink of the vlan. >>>>>>> >>>>>>> This is RFC until someone can test it against older kernels that >>>>>>> might >>>>>>> need to be supported. This works on today's fcoe-next kernel with a >>>>>>> mix of fcoe and fnic. I also tried it with a mix of fcoe and >>>>>>> qla2xxx (without a vendor library for the latter, it is ignored). >>>>>> I tried this under RHEL5.4 and it works, although I wasn't able to >>>>>> test with VLANs. >>>>>> >>>>>> There is another somewhat-related issue that I ran across on RHEL5.4. >>>>>> The device passed to scsi_add_host() is from >>>>>> netdev->class_dev.dev->parent. >>>>>> I don't understand why that parent deref is there. For the enic >>>>>> driver, >>>>>> the parent is a bridge, so fcoeadm -i shows the bridge device. For >>>>>> ixgbe, >>>>>> I assume fcoeadm -i works correctly although I don't have a RHEL >>>>>> setup with >>>>>> ixgbe just now. So, is enic doing something wrong or is fcoe wrong? >>>>>> It seems to me that fcoe is wrong, but the parent deref must be >>>>>> there for >>>>>> a reason. Is the device supposed to be a net device instead of a >>>>>> pci device, >>>>>> such that the parent is usually the pci device? >>>>>> >>>>> scsi_add_host wants the device with dma settings/restrictions, so >>>>> later >>> >>> One correction here. For vports with James's patch we do not have to >>> pass in the pci device, but I am not sure if the netdev will work >>> either. >>> >>>>> in functions like scsi_alloc_queue/__scsi_alloc_queue it can set the >>>>> block/queue segment/dma/scatterlist settings with it. Does the netdev >>>>> device have that? Maybe for upstream it does and for RHEL 5 it did >>>>> not. >>>>> I think for RHEL 5.4, there was a difference between what upstream >>>>> netdev device and what RHEL's netdev device have/are, because of the >>>> I mean I think (thought at the time) that upstream's netdev device >>>> pointed to the pci device, but in RHEL 5.4 the netdev->class_dev.dev >>> >>> Argh, I guess it looks like the upstream netdev device points to a net >>> device only. I see the netdev->dev.parent points to the pci device's >>> device. >>> >>> For normal scsi drivers we pass the pci dev to scsi_add_host. When >>> vports are in use then with JamesS's dev_to_nonscsi_dev patch we can >>> pass in the device from the vport or scsi_host or whatever, and >>> dev_to_nonscsi_dev will find the first non scsi object. >>> >>> So if the netdev device does not have dma restrictions limits then what >>> we are passing into scsi_add_host is wrong for the non vport case, or >> >> I miswrote that. If the netdev device does not have the dma >> restrictions then it is wrong for the vport and non vport case since >> the first non scsi object is going to be the netdevice device, and we >> want the pci device. >> >>> scsi-ml needs to be modified to find the parent with dma restrictions >>> for fcoe correctly. > > So for RHEL 5.x, it sounds like enic is doing the wrong thing. > netdev->dev->parent should point to the PCI device, but instead > netdev->dev does, and the parent is the bridge. >
Actually, I think I messed up on fcoe in RHEL 5.x. It looks like enic uses SET_NETDEV_DEV like it should and other drivers do. In RHEL 5 that sets the the pci device to netdev->class_dev.dev. For fcoe then I should pass scsi_add_host netdev->class_dev.dev. For upstream, I think for the non vport case fcoe should be passing scsi_add_host netdev->dev.parent. _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
