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.
This is not causing a problem except for libhbalinux, and it's
unlikely anyone needs to run FCoE on an enic since an fnic is available
from the same device. The only reason I tried it is to see what
would happen and to test libhbalinux.
Thanks a lot for the explanation.
Joe
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
