[ofa-general] QoS RFC / how its linked to the networking stack QoS?

Or Gerlitz ogerlitz at voltaire.com
Sun Aug 5 01:30:03 PDT 2007


Sean Hefty wrote:
>> 4. IPoIB ---------

>> IPoIB already query the SA for its broadcast group information. The 
>> additional functionality required is for IPoIB to provide the
>> broadcast group SL, MTU, and RATE in every following PathRecord query
>> performed when a new UDAV is needed by IPoIB. We could assign a
>> special Service-ID for IPoIB use but since all communication on the
>> same IPoIB interface shares the same QoS-Level without the ability to
>>  differentiate it by target service we can ignore it for simplicity.

> Rather than IPoIB specifying SL, MTU, and rate with PR queries, it 
> should specify TClass and FlowLabel.  This is necessary for IPoIB to 
> span IB subnets.

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.

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)

 From the man pages I understand that the stack uses those socket 
options to decide which networking queue would be used for the packet. 
 From the quick 802.1q code review I conclude that the driver has some 
scheme which it uses to map skb->priority to a priority field it sets in 
the vlan header.

Or.




More information about the general mailing list