Jason Gunthorpe <jguntho...@obsidianresearch.com> wrote:
> Or Gerlitz wrote:

>> Jason, as the change log explains, under Ethernet link type the code
>> (see mlx4_resolve_grh_to_l2) goes and extracts the Ethernet L2 info
>> (mac and vlan, look on the last patch) from the GID.
>
> Looking at the control flow of the actual code, there is no reason it
> needs to know the link type, except to generate that error code. Why
> can't it set the slid, dlid and MAC fields in mlx4_ah simultaneously?

If you look on patch 6/7 @ mlx4_resolve_grh_to_l2, you would see this section

+               if (vid != 0xffff) {
+                       ah->av.port_pd |= htonl(1 << 29);
+                       ah->vlan = vid | ((attr->sl & 7) << 13);
+               }

this bit in the PD tells the HW  to add VLAN header to the packet and
sets the user priority bits for that vlan from the SL, we want to do
that only for Ethernet link type.

>> AH creation is app's slow path, e.g the equivalent of session
>> creation, so I wouldn't bother too much on perf, on the being elegant
>> side, I'll check if/how I can plant/cache the link type for the ah
>> creation code to use.

> Still, the MPI people regularly seem to have job startup problems, no
> idea how many AH's they end up creating at startup though..


Under IB job startup problems relates to SA scalability, generally under any
transport @ large scale there could be more issues, I don't think AH
creation time
is among them.

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to