On 8/27/2013 4:47 PM, Neil Horman wrote:
On Tue, Aug 27, 2013 at 11:17:20AM -0700, Gerald Stanje wrote:
So the missing priority flow control is the only limitation?
I think so, yes. At least its the only direct limitation.
FCoE expects something close to a lossless fabric so if you have
congestion on the network and start dropping FCoE this will hurt
performance/usability.
Although if you run PFC or just flow control on the real physical
devices "ethx" then there should be no limitation. With PFC you
will need to ensure the FCoE traffic is en-queued on the correct
traffic class. This is done by setting the skb->priority.
Is the LUID Exchange not necessary in FCoE VN2VN mode?
That I'm not sure about.
- Probe Request (#1) (Multicast: All_VN2VN_Enode_MACs)
- Claim Notification (Multicast: All_VN2VN_Enode_MACs, inc. FC-4
attributes)
- Beacon (Multicast: Send every Beacon_Period)
On the target side (open fcoe) I just need to start the following services
without any lldpad and further dcbtool settings?
Well, you still want to run lldpad because there might be other exchanges that
other elements of the stack need, like the vlan id's that fcoe runs over. If
you're auto creating vlans. Although I'm not quite sure how lldpad works with
tap devices. It should work, I just don't know what it looks like to the peer.
Well typically your tap device will be behind a linux bridge or ovs
instance right? In this case the linux bridge will drop the LLDP packets
because they use the nearest bridge or nearest customer bridge MAC
address. An OVS bridge would likely depend on the flow configuration but
if it is acting as a standards based L2 bridge it should also drop the
LLDP packets.
I think the best way to go about this is to run lldpad with DCBX over
the real interface attached to the switch. Then lldp will talk to the
peer and any of the link attributes it negotiates DCBX or otherwise need
to be pushed up the stack. In this case you could configure PFC on the
real device and then its just a matter of classifying the FCoE packets
so they get put in the right traffic class as noted above.
.John
Neil
lldpad -k # terminate curreny running lldpad
service lldpad stop # just in case if it's started
service fcoe restart
echo eth2.569 > /sys/module/libfcoe/parameters/create_vn2vn
echo eth2.569 > /sys/module/libfcoe/parameters/enable
dcbtool sc eth2 dcb off # switch dcb off
Thanks,
Gerald
-----Original Message-----
From: Neil Horman [mailto:[email protected]]
Sent: Monday, August 26, 2013 12:50 PM
To: Gerald Stanje
Cc: [email protected]
Subject: Re: [Open-FCoE] DCBTool fails on tap0
On Mon, Aug 26, 2013 at 12:04:28PM -0700, Gerald Stanje wrote:
Hello Neil,
What's the workaround?
Thanks,
Gerald
To the best of my knoweldge, just don't set dcb settings on the adapter.
IIRC if your adapter doesn't support dcb, then you just send vlan
encapsulated fcoe frames on the same output queue as any other traffic.
You loose the ability to do hardware priority classification of course,
but theres no way around that Neil
-----Original Message-----
From: Neil Horman [mailto:[email protected]]
Sent: Monday, August 26, 2013 11:28 AM
To: Gerald Stanje
Cc: [email protected]
Subject: Re: [Open-FCoE] DCBTool fails on tap0
On Mon, Aug 26, 2013 at 10:50:55AM -0700, Gerald Stanje wrote:
Hello,
I use VN2VN mode and tried to create the following topology:
eth2.569 (ixgbe) tap0.569------ fcoe
target
| |
--------------- virbr1---------------
I attached my script including output and the syslog at the end.
Why does the call dcbtool fail with this message: Device not found,
link down or DCB not enabled???
Because the tap0 interface, being a software defined virtual interface
has no hardware to enable DCB on.
Neil
_______________________________________________
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
_______________________________________________
fcoe-devel mailing list
[email protected]
http://lists.open-fcoe.org/mailman/listinfo/fcoe-devel
