[ofa-general] [PATCH 1/4] ib/ipoib: specify TClassand FlowLabelwith PR queries for QoS support

[Sean Hefty]

>Well, the MTU isn't explicity carried in the headers, but if you send
>a 2K packet into a path that only supports 1K MTU then it will be
>discarded. In that sense the MTU is included in the headers.

This is what I meant by the MTU is implied by the other fields.  I was thinking
about it this way.  If a PR query contains the SLID, DLID, SL, I would expect
the SA to lookup the MTU for this path and return it.  Is there any advantage or
reason to include the MTU in such a query?
 
Taking this across subnets, if a PR query contains the SGID, DGID, TC, and FL,
does this change whether the MTU should be specified?  I'm not trying to argue
against including the MTU, but I don't know if IPoIB or the SA should specify
it.  (And I'm neither an IPoIB nor SA expert.)

>The MTU of every unicast path used must be greater than the Linux
>interface MTU so that the stack produces correctly sized fragments.

As you mentioned, this doesn't holds for IPoIB-CM.  The MTU of the path is less
than the MTU sent by the stack, and the path MTUs could differ, including being
less than the broadcast MTU.  (I don't know that the implementation supports
different path MTUs, but it could in theory.)

>If you want to use the 1k is fast feature of a tavor then I was under
>the impression that was done under a reduced IP interface MTU? Linux
>has no per-arp entry MTU so I don't know how you'd integrate the idea
>of different L2 destinations having different MTUs with the current
>stack.

Couldn't IPoIB fragment the packets if it needed?  (Not sure what that would do
to the performance.)  How does IPoIB-CM handle the case where the device MTU is,
say, 64k, but the remote side only supports UD?

- Sean