Re: [PATCH v4 for-next 04/12] IB/ipoib: Return IPoIB devices matching connection parameters

2015-05-28 Thread Jason Gunthorpe
On Thu, May 28, 2015 at 02:51:51PM +0300, Haggai Eran wrote: > > But RDMA CM doesn't provide the QPN. So when RDMA CM searches the > > netdevs for an address it cannot *uniquely* map to a IPoIB interface. > This is technically true, but if someone configures their system that > way, they will als

Re: [PATCH v4 for-next 04/12] IB/ipoib: Return IPoIB devices matching connection parameters

2015-05-28 Thread Haggai Eran
On 21/05/2015 20:43, Jason Gunthorpe wrote: > On Thu, May 21, 2015 at 08:33:53AM +0300, Haggai Eran wrote: > >> To create a new child interface on the default P_Key, its possible to >> use iproute: >> # ip link add link ib0 name ib0.1 type ipoib > > Uh.. > > A key invariant of the IP stack is th

Re: [PATCH v4 for-next 04/12] IB/ipoib: Return IPoIB devices matching connection parameters

2015-05-21 Thread Jason Gunthorpe
On Thu, May 21, 2015 at 08:33:53AM +0300, Haggai Eran wrote: > To create a new child interface on the default P_Key, its possible to > use iproute: > # ip link add link ib0 name ib0.1 type ipoib Uh.. A key invariant of the IP stack is that is it possible to uniquely identify the ingress device.

Re: [PATCH v4 for-next 04/12] IB/ipoib: Return IPoIB devices matching connection parameters

2015-05-21 Thread Or Gerlitz
On Thu, May 21, 2015 at 9:33 AM, Haggai Eran wrote: >> you can use non default pkeys as well here. >> $ ip link add link ib0 name ib0.1 type ipoib pkey 0x8001 > Right. I think when we started development of the namespaces patches > these child interfaces (rtnetlink with pkey) didn't work for us,

Re: [PATCH v4 for-next 04/12] IB/ipoib: Return IPoIB devices matching connection parameters

2015-05-20 Thread Haggai Eran
On 21/05/2015 08:48, Or Gerlitz wrote: > On Thu, May 21, 2015 at 8:33 AM, Haggai Eran wrote: >> On 20/05/2015 02:55, Jason Gunthorpe wrote: >>> On Sun, May 17, 2015 at 08:51:00AM +0300, Haggai Eran wrote: > From: Guy Shapiro > > Implement the get_net_device_by_port_pkey_ip callback th

Re: [PATCH v4 for-next 04/12] IB/ipoib: Return IPoIB devices matching connection parameters

2015-05-20 Thread Haggai Eran
On 20/05/2015 02:55, Jason Gunthorpe wrote: > On Sun, May 17, 2015 at 08:51:00AM +0300, Haggai Eran wrote: >> For each ipoib device we iterate through all upper devices when searching >> for a matching IP, in order to support bonding. > > Checking an IP address in a packet against a device without

Re: [PATCH v4 for-next 04/12] IB/ipoib: Return IPoIB devices matching connection parameters

2015-05-20 Thread Or Gerlitz
On Thu, May 21, 2015 at 8:33 AM, Haggai Eran wrote: > On 20/05/2015 02:55, Jason Gunthorpe wrote: >> On Sun, May 17, 2015 at 08:51:00AM +0300, Haggai Eran wrote: >>> > From: Guy Shapiro >>> > >>> > Implement the get_net_device_by_port_pkey_ip callback that returns network >>> > device to ib_core

Re: [PATCH v4 for-next 04/12] IB/ipoib: Return IPoIB devices matching connection parameters

2015-05-20 Thread Haggai Eran
On 20/05/2015 02:55, Jason Gunthorpe wrote: > On Sun, May 17, 2015 at 08:51:00AM +0300, Haggai Eran wrote: >> > From: Guy Shapiro >> > >> > Implement the get_net_device_by_port_pkey_ip callback that returns network >> > device to ib_core according to connection parameters. Check the ipoib >> > de

Re: [PATCH v4 for-next 04/12] IB/ipoib: Return IPoIB devices matching connection parameters

2015-05-20 Thread Haggai Eran
On 19/05/2015 21:28, Jason Gunthorpe wrote: > On Sun, May 17, 2015 at 08:51:00AM +0300, Haggai Eran wrote: > >> +#if IS_ENABLED(CONFIG_IPV6) >> +struct sockaddr_in6 *addr_in6 = (struct sockaddr_in6 *)addr; >> +#endif >> +__be32 ret_addr; >> + >> +switch (addr->sa_family) { >> +case

Re: [PATCH v4 for-next 04/12] IB/ipoib: Return IPoIB devices matching connection parameters

2015-05-19 Thread Jason Gunthorpe
On Sun, May 17, 2015 at 08:51:00AM +0300, Haggai Eran wrote: > +#if IS_ENABLED(CONFIG_IPV6) > + struct sockaddr_in6 *addr_in6 = (struct sockaddr_in6 *)addr; > +#endif > + __be32 ret_addr; > + > + switch (addr->sa_family) { > + case AF_INET: > + in_dev = in_dev_get(dev);