Sean Hefty wrote:
I wonder how you think the suggested scheme for IPoIB plugs into the
existing QoS flow at the Linux network stack. Looking on the man pages
of tcp(7) and ip(7) I see that there's a SOL_SOCKET level option of
SO_PRIORITY and SOL_IP level option of IP_TOS.
I was looking at IB routing, not IP routing. IPv6 uses flow info,
which, from what I can tell, is traffic class and flow label.
Indeed, that the IP_TOS option is related to IP routing and the
SO_PRIORITY option might be more related to internal net stack QoS such
as Priority Queuing, where both are beyond the scope of IPoIB.
However, As I reported below, for IPoEth the equivalent of IPoIB such as
the 802.1q and e1000 drivers are using skb->priority to derive the
"Ethernet QoS" which is the equivalent the SL in the LRH etc.
Looking lower in the stack, on the IPoEth scheme where the 802.1q is
used for the VLAN header generation, the code seems to generate the
p_bits field of the header using skb->priority (see the call to
vlan_dev_get_egress_qos_mask() from vlan_dev_hard_header() at
net/8021q/vlan_dev.c)
Someone with more knowledge of IPoIB than me needs to provide input
here. I thought the use of different PKeys was similar to the selection
of a VLAN.
Yes, use of pkeys with IPoIB is a similar concept for use of VLANs with
IPoEth, the point here, is that Ethernet QoS comes into play only when
VLANs are used, since the standard MAC header does not specify any QoS.
For IPoIB (no GRH case, omitting IB transport header) you would have
< LRH | IPoIB header | IP header | etc >
and for IPoEth using 802.1q VLANs
< MAC header | 802.1q vlan tag | IP header | etc >
the vlan tag has 12 bits of "vlan id" (the equiv of pkey), 3 bits of
priority (the equiv of the SL) and one more bit i don't remember.
Or.
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
