On Thu, Feb 9, 2017 at 2:15 AM, Parav Pandit <parav@xxxxxxxxxxxx> wrote: > >> -----Original Message----- >> From: Jason Gunthorpe [mailto:jgunthorpe@xxxxxxxxxxxxxxxxxxxx] >> Sent: Wednesday, February 8, 2017 6:02 PM >> To: Parav Pandit <parav@xxxxxxxxxxxx> >> Cc: Matan Barak <matanb@xxxxxxxxxxxxxxxxxx>; Roland Dreier >> <roland@xxxxxxxxxxxxxxx>; linux-rdma@xxxxxxxxxxxxxxx; Matan Barak >> <matanb@xxxxxxxxxxxx> >> Subject: Re: Need to set if_index in ib_init_ah_from_wc() ? >> >> On Thu, Feb 09, 2017 at 12:00:09AM +0000, Parav Pandit wrote: >> >> > > That still breaks link local addresses on vlan devices, so it is an >> > > ugly hack, not a solution. >> > >> > In presence of vlan, shouldn't we be passing the ifindex of the vlan >> netdev? >> >> yes, that is exactly my point... > > Oh ok. I get it. I am on right path to fix it than. > > Additionally, > when there is macvlan based slave device present on this vlan device, I will pass the ifindex of that particular netdev. > Now since we don't have MAC address coming in ib_wc nor in IB/RoCEv2 Annex spec, code needs to refer to the > (a) ifaddr of the vlan netdev > and > (b) ifaddr of the slave netdevs > Compare the DGID of the grh with ifaddr and use that netdev's ifindex for the first matching entry. > > Sounds reasonable now? > Since we don't get the DMAC address, I think the GID cache shouldn't carry entries which the hardware can't differentiate upon. It might be ok for some cases in the transmit side (as you choose the smac based on the netdev attached to the GID entry, but if you add a vxlan based interface, you won't be able to add the appropriate headers). We can leave this as is or making it symmetrical. So, when adding a GID, we need to consult the hardware capabilities regarding the metadata it can provide in the completion. If the hardware isn't capable of creating/stripping one of the headers of this netdev, there's no reason to add it. If the hardware supports creating/stripping the required headers but it doesn't support reporting them in the completion or all fields are supported but there are conflicting entries, you could either consult the ingress route before adding these GIDs or add them both and consult the ingress route when creating an AH from the completion entry and GRH data. I think adding them both, selecting the first one and validating with the ingress route is the way to go. The link local address falls into this case as well. > >> >> Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
