On Thu, Jul 29, 2010 at 08:09:31PM +0300, Eli Cohen wrote:
> Add a new API, resolve_eth_ll_gid(), which resolves a GID to layer 2
> address information. The GID resembles an IPv6 link local address
> and encodes the MAC address and the VLAN tag within it. The function
> accepts the destination GID, port number and source GID index and
> returns the MAC VLAN and indications whether the remote address is
> tagged VLAN and whether the address is multicast.
Is it reasonable for the receiver to have an sgid table entry for
every vlan supported?
resolve_eth_gid should probably fail if dgid vlan != sgid vlan..
> +int resolve_eth_gid(struct ibv_pd *pd, uint8_t port_num,
> + union ibv_gid *dgid, uint8_t sgid_index,
> + uint8_t mac[], uint16_t *vlan, uint8_t *tagged,
> + uint8_t *is_mcast);
union ibv_gid * should be const (and const flowed down)
> +static int is_multicast_gid(union ibv_gid *gid)
> +{
> + return gid->raw[0] == 0xff ? 1 : 0;
> +}
This ternary if is kinda redundant?
> +static int resolve_grh(union ibv_gid *dgid, uint8_t *mac, uint8_t *is_mcast)
> +{
Funny name for the function? It does not touch GRHs?
> + *vlan = get_vlan_id(&sgid);
> + *tagged = *vlan;
It is hard to see what you are trying to do here, can you document
this GID address format you invented? vlan 0 is not special, you
shouldn't use it to mean untagged packets. I'm guessing the scheme
is if the GID has the 0xFFFE bit then it should be untagged
otherwise it should be tagged with the VID in bytes 11/12? If so
then this computation if *tagged is wrong, it prevents someone
creating tagged vlan id 0 packets, which is a valid thing to do.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
