[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