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.
_______________________________________________
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
