On 7/1/10 12:11 PM, Vasu Dev wrote:
> On Thu, 2010-07-01 at 10:44 -0700, Joe Eykholt wrote:
>> On 7/1/10 10:39 AM, Joe Eykholt wrote:
>>> On 7/1/10 10:19 AM, Vasu Dev wrote:
>>>> This reverts commit cc0136c2e9c10e889cb36e39710c0eb10707b396.
>>>>
>>>> That commit introduced vlan id info to WWPN but WWPN needs to
>>>> remain static as an unique port identifier in the fabric, therefore
>>>> variable fabric vlan id info doesn't need to be embedded inside WWPN.
>>>>
>>>> After this revert, port arg to fcoe_wwn_from_mac is always zero
>>>> but still leaving it as-is might be okay to later allow users
>>>> to use NAA 2 scheme with this additional identifier, so limiting
>>>> to only this revert is sufficient for now to get rid off vlan id
>>>> in WWPN but I'm also okay to remove port arg if others wants that.
>>>
>>> I agree that the fcoe_wwn_from_mac() should keep the port arg for scheme 2.
>>>
>>> The patch looks OK but it means that only one VLAN should be used at a time
>>> per network interface. Otherwise, they all would get the same port name.
>>> That might work if the fabrics/VSANs are distinct, but it will confuse
>>> management
>>> software and IT people.
>>
>> Also note that this could require a zoning change for existing users.
> Yes that would be required each time WWPN is changed and therefore not
> to change WWPN using vlan id. I gather you agree to that along with your
> good point to enable additional vlan i/f creation with new unique WWPN
> and for that your suggestion below of optionally supplying port name
> should work well.
It's not too big of a concern, but if someone is using VLANs successfully
today, then this code change would require them to change configuration
when they upgrade to this version of code even if their VLAN didn't change.
That's all I meant. I don't know how many users this affects, maybe none.
>>> Perhaps its time to optionally specify the port name when creating an
>>> interface.
>>>
>
> That would be similar to NPIV port creation and I can add optional
> "<WWPN>:<WWNN>" to fcoe create for that and I guess that should be okay
> with all.
I'd prefer comma-separated parameters like in some module paramters,
that way we could allow colons inside the WWPN someday. This opens
a can of worms that Rob is addressing, I think.
>>> Perhaps we should check for port name uniqueness among all
>>> the other libfc or fcoe ports before creating an lport.
>>>
>
> May not be needed since fabric login should fail if duplicate PN is not
> okay to fabric and also it may be okay to login with same PN to
> different fabrics over vlans.
Maybe not needed, but it's safer to add that restriction. Not sure how urgent.
Fabric login wouldn't fail if they're on the same fabric ... it implies
the other port is logged out.
Even if they are different fabrics, they may be under the same management
software which is why they should still be unique.
Since it's easy to get duplicates, we should at least print a warning,
but I think it's safer to refuse the create if the WWN clashes with one
we already have.
Joe
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
