* Re: [PATCH] net: sched: One function call less in em_meta_change() after error detection
From: Lino Sanfilippo @ 2015-01-31 22:51 UTC (permalink / raw)
To: SF Markus Elfring, David S. Miller, Jamal Hadi Salim, netdev
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <54CD5529.5060209@users.sourceforge.net>
On 31.01.2015 23:20, SF Markus Elfring wrote:
>>> I find that all these cases correspond to the current Linux coding
>>> style documentation, doesn't it?
>>
>> Sure, I think it does.
>
> Thanks for your acknowledgement.
>
>
>> But it was not coding style violation what I was reffering to.
>
> Do you suggest any fine-tuning for the affected documentation
> so that I would tweak my update suggestion once more?
>
No I dont think that any documentation has to be adjusted. If you agree
with me you should adjust the patch accordingly and resend it. Otherwise
keep it as it is.
Regards,
Lino
^ permalink raw reply
* Re: [PATCH] net: ipv6: Make address flushing on ifdown optional - v2
From: David Miller @ 2015-02-01 1:17 UTC (permalink / raw)
To: dsahern; +Cc: netdev, hannes
In-Reply-To: <1422504065-17445-1-git-send-email-dsahern@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Wed, 28 Jan 2015 21:01:05 -0700
> @@ -3032,8 +3037,9 @@ static int addrconf_ifdown(struct net_device *dev, int how)
> {
> struct net *net = dev_net(dev);
> struct inet6_dev *idev;
> - struct inet6_ifaddr *ifa;
> + struct inet6_ifaddr *ifa, *tmp;
> int state, i;
> + struct list_head del_list;
Please order local variable declarations from longest to shortest line
(ie. reverse christmas tree) when it is easy to do so.
> + /*
> + * on NETDEV_DOWN events do not flush managed (user configured)
> + * addresses unless configured to do so. If the address is not
> + * deleted reset flags and state such that DAD is re-done on a
> + * subsequent link up.
> + */
Comments in the networking are to be formatted:
/* Like
* this.
*/
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] tcp: use SACK RTTs for CC
From: David Miller @ 2015-02-01 1:26 UTC (permalink / raw)
To: kennetkl; +Cc: netdev
In-Reply-To: <1422558483-6168-1-git-send-email-kennetkl@ifi.uio.no>
From: Kenneth Klette Jonassen <kennetkl@ifi.uio.no>
Date: Thu, 29 Jan 2015 20:08:03 +0100
> Current behavior only passes RTTs from sequentially acked data to CC.
>
> If sender gets a combined ACK for segment 1 and SACK for segment 3, then the
> computed RTT for CC is the time between sending segment 1 and receiving SACK
> for segment 3.
>
> Pass the minimum computed RTT from any acked data to CC, i.e. time between
> sending segment 3 and receiving SACK for segment 3.
>
> Signed-off-by: Kenneth Klette Jonassen <kennetkl@ifi.uio.no>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] hyperv: Fix the error processing in netvsc_send()
From: David Miller @ 2015-02-01 1:32 UTC (permalink / raw)
To: haiyangz; +Cc: olaf, netdev, jasowang, driverdev-devel, linux-kernel
In-Reply-To: <1422563689-31036-1-git-send-email-haiyangz@microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
Date: Thu, 29 Jan 2015 12:34:49 -0800
> The existing code frees the skb in EAGAIN case, in which the skb will be
> retried from upper layer and used again.
> Also, the existing code doesn't free send buffer slot in error case, because
> there is no completion message for unsent packets.
> This patch fixes these problems.
>
> (Please also include this patch for stable trees. Thanks!)
>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] drivers: net: cpsw: make cpsw_ale.c a module to allow re-use on Keystone
From: David Miller @ 2015-02-01 1:36 UTC (permalink / raw)
To: m-karicheri2
Cc: w-kwok2, mugunthanvnm, tony, prabhakar.csengg, grygorii.strashko,
lokeshvutla, mpa, lsorense, netdev, linux-kernel, arnd
In-Reply-To: <1422573351-5603-2-git-send-email-m-karicheri2@ti.com>
From: Murali Karicheri <m-karicheri2@ti.com>
Date: Thu, 29 Jan 2015 18:15:51 -0500
> NetCP on Keystone has cpsw ale function similar to other TI SoCs
> and this driver is re-used. To allow both ti cpsw and keystone netcp
> to re-use the driver, convert the cpsw ale to a module and configure
> it through Kconfig option CONFIG_TI_CPSW_ALE. Currently it is statically
> linked to both TI CPSW and NetCP and this causes issues when the above
> drivers are built as dynamic modules. This patch addresses this issue
>
> While at it, fix the Makefile and code to build both netcp_core and
> netcp_ethss as dynamic modules. This is needed to support arm allmodconfig.
> This also requires exporting of API calls provided by netcp_core so that
> both the above can be dynamic modules.
>
> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH net-next v2 0/6] net: Add STT support.
From: David Miller @ 2015-02-01 1:40 UTC (permalink / raw)
To: pshelar; +Cc: netdev
In-Reply-To: <1422574156-1831-1-git-send-email-pshelar@nicira.com>
From: Pravin B Shelar <pshelar@nicira.com>
Date: Thu, 29 Jan 2015 15:29:16 -0800
> Following patch series adds support for Stateless Transport
> Tunneling protocol.
> STT uses TCP segmentation offload available in most of NIC. On
> packet xmit STT driver appends STT header along with TCP header
> to the packet. For GSO packet GSO parameters are set according
> to tunnel configuration and packet is handed over to networking
> stack. This allows use of segmentation offload available in NICs
I don't like this at all.
Routers _absolutely_ depend upon the ability to make TCP flows back
off by dropping packets in various ways (tail drop, RED random drops,
etc.). STT violates this completely.
It's _NOT_ TCP, you can't put lipstick on a pig and pretend it's not a
pig. You need to use something that indicates it's flow properties,
a datagram protocol. Either via an existing one or by creating a new
one.
I know you want to do this mass TCP behavioral violation because of
TSO. But that's too bad. The ends do not justify the means.
I also don't buy the argument that "people can put arbitrary changes
into their kernel to do stuff like that".
They can't do it to the stack I'm willing to maintain, and that's what
matters for %99 of systems out there.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: icmp: use percpu allocation
From: David Miller @ 2015-02-01 1:48 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1422575889.21689.44.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 29 Jan 2015 15:58:09 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Get rid of nr_cpu_ids and use modern percpu allocation.
>
> Note that the sockets themselves are not yet allocated
> using NUMA affinity.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] net: sched: fix panic in rate estimators
From: David Miller @ 2015-02-01 1:55 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, john.fastabend
In-Reply-To: <1422581412.21689.53.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 29 Jan 2015 17:30:12 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Doing the following commands on a non idle network device
> panics the box instantly, because cpu_bstats gets overwritten
> by stats.
>
> tc qdisc add dev eth0 root <your_favorite_qdisc>
> ... some traffic (one packet is enough) ...
> tc qdisc replace dev eth0 root est 1sec 4sec <your_favorite_qdisc>
...
> Lets play safe and not use an union : percpu 'pointers' are mostly read
> anyway, and we have typically few qdiscs per host.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: John Fastabend <john.fastabend@gmail.com>
> Fixes: 22e0f8b9322c ("net: sched: make bstats per cpu and estimator RCU safe")
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH 1/3] netlabel: Deletion of an unnecessary check before the function call "cipso_v4_doi_putdef"
From: Paul Moore @ 2015-02-01 2:20 UTC (permalink / raw)
To: SF Markus Elfring
Cc: David S. Miller, netdev, LKML, kernel-janitors, Julia Lawall
In-Reply-To: <54CD4A7D.8000802@users.sourceforge.net>
On Sat, Jan 31, 2015 at 4:34 PM, SF Markus Elfring
<elfring@users.sourceforge.net> wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sat, 31 Jan 2015 19:09:50 +0100
>
> The cipso_v4_doi_putdef() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> net/netlabel/netlabel_mgmt.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Acked-by: Paul Moore <paul@paul-moore.com>
> diff --git a/net/netlabel/netlabel_mgmt.c b/net/netlabel/netlabel_mgmt.c
> index 8b3b789..f5807f5 100644
> --- a/net/netlabel/netlabel_mgmt.c
> +++ b/net/netlabel/netlabel_mgmt.c
> @@ -242,8 +242,7 @@ static int netlbl_mgmt_add_common(struct genl_info *info,
> return 0;
>
> add_failure:
> - if (cipsov4)
> - cipso_v4_doi_putdef(cipsov4);
> + cipso_v4_doi_putdef(cipsov4);
> if (entry)
> kfree(entry->domain);
> kfree(addrmap);
> --
> 2.2.2
>
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH 2/3] netlabel: Deletion of an unnecessary check before the function call "cipso_v4_doi_free"
From: Paul Moore @ 2015-02-01 2:22 UTC (permalink / raw)
To: SF Markus Elfring
Cc: David S. Miller, netdev, LKML, kernel-janitors, Julia Lawall
In-Reply-To: <54CD4AF0.7070102@users.sourceforge.net>
On Sat, Jan 31, 2015 at 4:36 PM, SF Markus Elfring
<elfring@users.sourceforge.net> wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sat, 31 Jan 2015 19:35:59 +0100
>
> The cipso_v4_doi_free() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> net/netlabel/netlabel_cipso_v4.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Acked-by: Paul Moore <paul@paul-moore.com>
> diff --git a/net/netlabel/netlabel_cipso_v4.c b/net/netlabel/netlabel_cipso_v4.c
> index 1796253..7fd1104 100644
> --- a/net/netlabel/netlabel_cipso_v4.c
> +++ b/net/netlabel/netlabel_cipso_v4.c
> @@ -324,8 +324,7 @@ static int netlbl_cipsov4_add_std(struct genl_info *info,
> return 0;
>
> add_std_failure:
> - if (doi_def)
> - cipso_v4_doi_free(doi_def);
> + cipso_v4_doi_free(doi_def);
> return ret_val;
> }
>
> --
> 2.2.2
>
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH 3/3] netlabel: Less function calls in netlbl_mgmt_add_common() after error detection
From: Paul Moore @ 2015-02-01 2:40 UTC (permalink / raw)
To: SF Markus Elfring
Cc: David S. Miller, netdev, LKML, kernel-janitors, Julia Lawall
In-Reply-To: <54CD4B5F.9010502@users.sourceforge.net>
On Sat, Jan 31, 2015 at 4:38 PM, SF Markus Elfring
<elfring@users.sourceforge.net> wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sat, 31 Jan 2015 21:55:48 +0100
>
> The functions "cipso_v4_doi_putdef" and "kfree" could be called in some cases
> by the netlbl_mgmt_add_common() function during error handling even if the
> passed variables contained still a null pointer.
>
> * This implementation detail could be improved by adjustments for jump labels.
>
> * Let us return immediately after the first failed function call according to
> the current Linux coding style convention.
>
> * Let us delete also an unnecessary check for the variable "entry" there.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> net/netlabel/netlabel_mgmt.c | 46 ++++++++++++++++++++++----------------------
> 1 file changed, 23 insertions(+), 23 deletions(-)
>
> diff --git a/net/netlabel/netlabel_mgmt.c b/net/netlabel/netlabel_mgmt.c
> index f5807f5..17f1ed5 100644
> --- a/net/netlabel/netlabel_mgmt.c
> +++ b/net/netlabel/netlabel_mgmt.c
...
> @@ -237,15 +235,17 @@ static int netlbl_mgmt_add_common(struct genl_info *info,
>
> ret_val = netlbl_domhsh_add(entry, audit_info);
> if (ret_val != 0)
> - goto add_failure;
> + goto free_address_map;
>
> return 0;
>
> -add_failure:
> - cipso_v4_doi_putdef(cipsov4);
> - if (entry)
> - kfree(entry->domain);
> +free_address_map:
> kfree(addrmap);
> +doi_put_def:
> + cipso_v4_doi_putdef(cipsov4);
> +free_domain:
> + kfree(entry->domain);
> +free_entry:
> kfree(entry);
> return ret_val;
> }
It would be nice if you could stick with the goto label naming style
in the rest of the file, e.g.
"add_free_addrmap"/"add_put_doi_def"/"add_free_domain"/"add_free_entry".
--
paul moore
www.paul-moore.com
^ permalink raw reply
* AF_NETDEV - device specific sockets
From: Zayats, Michael @ 2015-02-01 4:20 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hi,
I am looking for a generic mechanism that would allow network device drivers to provide socket interface to user and kernel space clients.
Such an interface might be used to provide access to important sub-streams of packets, alongside with device specific packet metadata, provided through msg_control fields of recv/sendmsg.
RX Metadata might include device specific information, such as queuing priorities applied, potential destination interface in case of switching hardware etc.
On the transmission, metadata might be used to indicate hardware specific required optimizations, as well as any other transformation or accounting required on the packet.
AF_PACKET based mechanism doesn't allow metadata to be exchanged between the client and the device driver.
Extending it would require extending of sk_buff and potentially additional per packet operations.
Generic Netlink is not intended to pass packets.
As I am trying to validate generic applicability of such a mechanism, I see that TUN driver is providing custom socket interface, in order to deal with user information through msg_control.
Only usable inside the kernel, through custom interface.
Proposed interface
------------------
Kernel side:
(struct proto *) should be added to struct net_device.
Device driver that is interested to support socket interface would populate the pointer.
User space:
After creating AF_NETDEV socket, the only successful operation would be setting SO_BINDTODEVICE option.
Once set, all socket operations would be implemented by calling functions, that are registered at struct proto on the appropriate net_device.
What do you think?
Would you see a better approach?
Some other mechanism that already exists for such a purpose?
Thanks,
Michael
^ permalink raw reply
* Re: AF_NETDEV - device specific sockets
From: John Fastabend @ 2015-02-01 4:41 UTC (permalink / raw)
To: Zayats, Michael; +Cc: netdev@vger.kernel.org
In-Reply-To: <FC8E8D0ECC753F45808079B18C3203FE1CCA0C@G4W3293.americas.hpqcorp.net>
On 01/31/2015 08:20 PM, Zayats, Michael wrote:
> Hi,
>
> I am looking for a generic mechanism that would allow network device
> drivers to provide socket interface to user and kernel space
> clients.
>
> Such an interface might be used to provide access to important
> sub-streams of packets, alongside with device specific packet
> metadata, provided through msg_control fields of recv/sendmsg.
>
> RX Metadata might include device specific information, such as
> queuing priorities applied, potential destination interface in case
> of switching hardware etc.
>
> On the transmission, metadata might be used to indicate hardware
> specific required optimizations, as well as any other transformation
> or accounting required on the packet.
>
> AF_PACKET based mechanism doesn't allow metadata to be exchanged
> between the client and the device driver. Extending it would require
> extending of sk_buff and potentially additional per packet
> operations. Generic Netlink is not intended to pass packets.
>
> As I am trying to validate generic applicability of such a mechanism,
> I see that TUN driver is providing custom socket interface, in order
> to deal with user information through msg_control. Only usable inside
> the kernel, through custom interface.
> Proposed interface
> ------------------
> Kernel side:
> (struct proto *) should be added to struct net_device.
> Device driver that is interested to support socket interface would populate the pointer.
>
> User space: After creating AF_NETDEV socket, the only successful
> operation would be setting SO_BINDTODEVICE option. Once set, all
> socket operations would be implemented by calling functions, that are
> registered at struct proto on the appropriate net_device.
>
> What do you think?
> Would you see a better approach?
> Some other mechanism that already exists for such a purpose?
It might help to come up with specific examples but an alternate
proposal would be to use skb->priority field and then mqprio to
steer the traffic to a specific queue and then bind attributes to
the queue.
For example the NIC offloaded QOS can be mapped on to queues and
then sockets mapped to the queues.
Another example would be to forward all traffic from one queue
to a virtual fuction in SR-IOV use case. We don't have an interface
to do this but I have been working on an API that could be used
for this.
In this case you don't need to modify AF_PACKET interface but
configure the device correctly. If you need per-packet control
you could use 'tc' or 'nftables' to do the steering.
.John
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH net] net: sched: fix panic in rate estimators
From: John Fastabend @ 2015-02-01 4:45 UTC (permalink / raw)
To: eric.dumazet; +Cc: David Miller, netdev
In-Reply-To: <20150131.175520.1521332119325954392.davem@davemloft.net>
On 01/31/2015 05:55 PM, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 29 Jan 2015 17:30:12 -0800
>
>> From: Eric Dumazet <edumazet@google.com>
>>
>> Doing the following commands on a non idle network device
>> panics the box instantly, because cpu_bstats gets overwritten
>> by stats.
>>
>> tc qdisc add dev eth0 root <your_favorite_qdisc>
>> ... some traffic (one packet is enough) ...
>> tc qdisc replace dev eth0 root est 1sec 4sec <your_favorite_qdisc>
> ...
>> Lets play safe and not use an union : percpu 'pointers' are mostly read
>> anyway, and we have typically few qdiscs per host.
>>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Cc: John Fastabend <john.fastabend@gmail.com>
>> Fixes: 22e0f8b9322c ("net: sched: make bstats per cpu and estimator RCU safe")
>
> Applied and queued up for -stable, thanks Eric.
>
Thanks Eric, looks like my "replace" test scripts never sent traffic
before the replace call.
Also I haven't seen any RCU splats in awhile so I'll send out a patch
to drop the qdisc_lock on ing_filter shortly.
--
John Fastabend Intel Corporation
^ permalink raw reply
* RE: AF_NETDEV - device specific sockets
From: Zayats, Michael @ 2015-02-01 5:04 UTC (permalink / raw)
To: John Fastabend; +Cc: netdev@vger.kernel.org
In-Reply-To: <54CDAE61.60100@gmail.com>
More specific example would be when NIC performs certain fast path processing,
while punting to the CPU for a slow path.
Slow path would be interested to know the punt reason.
Another example would be if specific NIC strips S-tag in QinQ case and would like to communicate the stripped
Tag to the client.
There might be many types of custom functionality, agreed between the NIC and the clients,
which is not generic or not practical enough for inclusion in the kernel.
That's why I am looking for a generic, socket like mechanism of device<->client, packet + metadata communication,
which wouldn't require core kernel modification.
Thanks,
Michael
-----Original Message-----
From: John Fastabend [mailto:john.fastabend@gmail.com]
Sent: Saturday, January 31, 2015 8:41 PM
To: Zayats, Michael
Cc: netdev@vger.kernel.org
Subject: Re: AF_NETDEV - device specific sockets
On 01/31/2015 08:20 PM, Zayats, Michael wrote:
> Hi,
>
> I am looking for a generic mechanism that would allow network device
> drivers to provide socket interface to user and kernel space clients.
>
> Such an interface might be used to provide access to important
> sub-streams of packets, alongside with device specific packet
> metadata, provided through msg_control fields of recv/sendmsg.
>
> RX Metadata might include device specific information, such as queuing
> priorities applied, potential destination interface in case of
> switching hardware etc.
>
> On the transmission, metadata might be used to indicate hardware
> specific required optimizations, as well as any other transformation
> or accounting required on the packet.
>
> AF_PACKET based mechanism doesn't allow metadata to be exchanged
> between the client and the device driver. Extending it would require
> extending of sk_buff and potentially additional per packet operations.
> Generic Netlink is not intended to pass packets.
>
> As I am trying to validate generic applicability of such a mechanism,
> I see that TUN driver is providing custom socket interface, in order
> to deal with user information through msg_control. Only usable inside
> the kernel, through custom interface.
> Proposed interface
> ------------------
> Kernel side:
> (struct proto *) should be added to struct net_device.
> Device driver that is interested to support socket interface would populate the pointer.
>
> User space: After creating AF_NETDEV socket, the only successful
> operation would be setting SO_BINDTODEVICE option. Once set, all
> socket operations would be implemented by calling functions, that are
> registered at struct proto on the appropriate net_device.
>
> What do you think?
> Would you see a better approach?
> Some other mechanism that already exists for such a purpose?
It might help to come up with specific examples but an alternate proposal would be to use skb->priority field and then mqprio to steer the traffic to a specific queue and then bind attributes to the queue.
For example the NIC offloaded QOS can be mapped on to queues and then sockets mapped to the queues.
Another example would be to forward all traffic from one queue to a virtual fuction in SR-IOV use case. We don't have an interface to do this but I have been working on an API that could be used for this.
In this case you don't need to modify AF_PACKET interface but configure the device correctly. If you need per-packet control you could use 'tc' or 'nftables' to do the steering.
.John
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: netfilter: Use rhashtable walk iterator
From: Patrick McHardy @ 2015-02-01 7:45 UTC (permalink / raw)
To: Herbert Xu
Cc: David Miller, tgraf, ying.xue, paulmck, netdev, netfilter-devel
In-Reply-To: <20150131043151.GA27524@gondor.apana.org.au>
On 31.01, Herbert Xu wrote:
> On Sat, Jan 31, 2015 at 02:13:56PM +1100, Herbert Xu wrote:
> >
> > No problems. Here is a new version of these two patches which
> > hopefully should work on netfilter as well.
>
> And here is the patch for netfilter.
>
> -- >8 --
> This patch gets rid of the manual rhashtable walk in nft_hash
> which touches rhashtable internals that should not be exposed.
> It does so by using the rhashtable iterator primitives.
>
> Note that I'm leaving nft_hash_destroy alone since it's only
> invoked on shutdown and it shouldn't be affected by changes
> to rhashtable internals (or at least not what I'm planning to
> change).
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: Patrick McHardy <kaber@trash.net>
Thanks Herbert!
^ permalink raw reply
* [PATCH] can: janz-ican3: fix type missmatch in assignment
From: Nicholas Mc Guire @ 2015-02-01 8:34 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Marc Kleine-Budde, linux-can, netdev, linux-kernel,
Nicholas Mc Guire
From: Nicholas Mc Guire <der.herr@hofr.at>
return type of wait_for_completion_timeout is unsigned long not int, this
patch removes the type missmatch by moving the call into the condition.
Signed-off-by: Nicholas Mc Guire <der.herr@hofr.at>
---
The return type of wait_for_completion_timeout is unsigned long not
int. This patch resolves the type missmatch by moving the call to
wait_for_completion_timeout into the condition.
Patch was compile tested only for x86_64_defconfig + CONFIG_CAN=m
CONFIG_COMPILE_TEST=y, CONFIG_MFD_CS5535=m, CONFIG_OLPC=y
CONFIG_MFD_JANZ_CMODIO=m, CONFIG_CAN_JANZ_ICAN3=m
Patch is against 3.19.0-rc6 -next-20150130
drivers/net/can/janz-ican3.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/can/janz-ican3.c b/drivers/net/can/janz-ican3.c
index 0eb4d18..4dd183a 100644
--- a/drivers/net/can/janz-ican3.c
+++ b/drivers/net/can/janz-ican3.c
@@ -1679,8 +1679,7 @@ static int ican3_get_berr_counter(const struct net_device *ndev,
if (ret)
return ret;
- ret = wait_for_completion_timeout(&mod->buserror_comp, HZ);
- if (ret == 0) {
+ if (!wait_for_completion_timeout(&mod->buserror_comp, HZ)) {
netdev_info(mod->ndev, "%s timed out\n", __func__);
return -ETIMEDOUT;
}
@@ -1705,8 +1704,7 @@ static ssize_t ican3_sysfs_show_term(struct device *dev,
if (ret)
return ret;
- ret = wait_for_completion_timeout(&mod->termination_comp, HZ);
- if (ret == 0) {
+ if (!wait_for_completion_timeout(&mod->termination_comp, HZ)) {
netdev_info(mod->ndev, "%s timed out\n", __func__);
return -ETIMEDOUT;
}
--
1.7.10.4
^ permalink raw reply related
* Re: Fwd: Throughput regression with `tcp: refine TSO autosizing`
From: Dave Taht @ 2015-02-01 8:45 UTC (permalink / raw)
To: Andrew McGregor
Cc: dstanley, Stig Thormodsrud, netdev, linux-wireless,
Jesper Dangaard Brouer, Derrick Pallas, Matt Mathis,
cerowrt-devel, Kathy Giori, Mahesh Paolini-Subramanya,
Jonathan Morton, Tim Shepard, Avery Pennarun
In-Reply-To: <CAA_e5Z46Bu+zZZFzf_ejzA35Gw3g1_OG85yv6yd7MpbwZcE-nw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 20483 bytes --]
This convo ended up being cut from netdev due to containing HTML.
I'd really like to get started on finally fixing WiFi starting in April.
---------- Forwarded message ----------
From: "Andrew McGregor" <andrewmcgr@gmail.com>
Date: Feb 1, 2015 12:07 AM
Subject: Re: [Cerowrt-devel] Fwd: Throughput regression with `tcp: refine
TSO autosizing`
To: "Avery Pennarun" <apenwarr@google.com>
Cc: "David Reed" <dpreed@reed.com>, "Dave Taht" <dave.taht@gmail.com>, "Jim
Gettys" <jg@freedesktop.org>, "Tim Shepard" <shep@alum.mit.edu>, "Matt
Mathis" <mattmathis@google.com>, "Jesper Dangaard Brouer" <
jbrouer@redhat.com>, "Jonathan Morton" <chromatix99@gmail.com>, "
cerowrt-devel@lists.bufferbloat.net" <cerowrt-devel@lists.bufferbloat.net>
> I think I have a good idea how to do it, actually. Or at least, I had a
design sketched out that was kind of plausible.
>
> In essence, we have a good way of controlling queues in the IP stack,
that being fq_codel. But aggregating wifi drivers have to pull all the
traffic straight through that and queue it themselves, with a different
rotation policy and (at present) no AQM.
>
> Well, that can be fixed. We need a transmission and aggregation
scheduler at the wifi layer that can do a per-station round-robin with a
time-based fairness policy, based on airtime. This has to be in the wifi
layer because that's where rate selection policy is, and you can't
calculate airtime until you know the selected rate, the current success
probabilities, and how much aggregation you're going to do within your time
budget. We need to be able to plug in per-flow and per-packet scheduling
and drop policies on top of that, to control scheduling of individual
packets into aggregates.
>
> We could also do the trick of assigning a target drop probability and
telling a Minstrel-like rate controller what drop probability we're after;
then you get the nice property that the transmission scheduler and rate
control are work-conserving and actually get faster when they get congested.
>
> There is also now the mathematics available to improve Minstrel, which is
about 80% of a truly optimal rate controller (interestingly, that math was
published in 2010, years after we did Minstrel; I had the intuition that it
was close to optimal but no way to do a proof).
>
> None of this is rocket science, but it is a pretty deep and complex
refactor of something that isn't the simplest code to start with. That
said, I'd not expect it to be more than around 1k LoC, it's just going to
be a real bear to test.
I think the best path forward is to do proof of concept on the two open
enough drivers we have - the mt76 and ath9k.
A lot of what is needed to make rational decisions is simply not available
from closed firmwares.
> I do have the feeling that the people receiving this email ought to be
sufficient to fix the problem, if we can direct enough time to it; for
myself, I have to think quite hard as to whether this should be my 20%
project.
There needs to be focus and direct funding for quite a few people. Felix
for one. It would be nice to acquire half an engineer from each of multiple
companies making wireless products and chips in a linaro like fashion, also.
> On Sun, Feb 1, 2015 at 2:06 PM, Avery Pennarun <apenwarr@google.com>
wrote:
>>
>> I would argue that insofar as the bufferbloat project has made a
>> difference, it's because there was a very clear message and product:
>> - here's what sucks when you have bufferbloat
>> - here's how you can detect it
>> - here's how you can get rid of it
>> - by the way, here's which of your competitors are already beating you
at it.
>>
>> It turns out you don't need a standards org in order to push any of
>> the above things. The IEEE exists to make sure things interop at the
>> MAC/PHY layer. The IETF exists to make sure things interop at the
>> higher layers. But bufferbloat isn't about interop, it's just a thing
>> that happens inside gateways, so it's not something you can really
>> write standards about. It is something you can turn into a
>> competitive advantage (or disadvantage, if you're a straggler).
>>
>> ...but meanwhile, if we want to fix bufferbloat in wifi, nobody
>> actually knows how to do it, so we are still at steps 1 and 2.
>>
>> This is why we're funding Dave to continue work on netperf-wrappers.
I still don't have POs for the other 75% of me this year. It is comforting
to have got such a public confirmation that I have at least this much
floor under me this year, tho.
>> Those diagrams of latency under load are pretty convincing. The
>> diagrams of page load times under different levels of latency are even
>> more convincing. First, we prove there's a problem and a way to
>> measure the problem. Then hopefully more people will be interested in
>> solving it.
Well, a wall of shame might help, I guess. I have a ton of data on a dozen
products that is miserable to see and should be quite embarrassing for the
vendors.
I'd prefer to spend time trying to fix the darn problem more directly, but
I would expect this tool will be of use in tracking improvements.
>>
>> On Sat, Jan 31, 2015 at 4:51 PM, <dpreed@reed.com> wrote:
>> > I think we need to create an Internet focused 802.11 working group that
>> > would be to the "OS wireless designers and IEEE 802.11 standards
groups" as
>> > the WHATML group was to W3C.
>> >
>> >
>> >
>> > W3C was clueless about the real world at the point WHATML was
created. And
>> > WHATML was a "revenge of the real" against W3C - advancing a wide
variety of
>> > important practical innovations rather than attending endless standards
>> > meetings with people who were not focused on solving actually important
>> > problems.
>> >
>> >
>> >
>> > It took a bunch of work to get WHATML going, and it offended W3C, who
became
>> > unhelpful. But the approach actually worked - we now have a Web that
really
>> > uses browser-side expressivity and that would never have happened if
W3C
>> > were left to its own devices.
>> >
>> >
>> >
>> > The WiFi consortium was an attempt to wrest control of pragmatic
direction
>> > from 802.11 and the proprietary-divergence folks at Qualcomm, Broadcom,
>> > Cisco, etc. But it failed, because it became thieves on a raft, more
>> > focused on picking each others' pockets than on actually addressing
the big
>> > issues.
>> >
>> >
>> >
>> > Jim has seen this play out in the Linux community around X. Though
there
>> > are lots of interests who would benefit by moving the engineering ball
>> > forward, everyone resists action because it means giving up the chance
at
>> > dominance, and the central group is far too weak to do anything beyond
>> > adjudicating the worst battles.
>> >
>> >
>> >
>> > When I say "we" I definitely include myself (though my time is limited
due
>> > to other commitments and the need to support my family), but I would
only
>> > play with people who actually are committed to making stuff happen -
which
>> > includes raising hell with the vendors if need be, but also effective
>> > engineering steps that can achieve quick adoption.
>> >
>> >
>> >
>> > Sadly, and I think it is manageable at the moment, there are moves out
there
>> > being made to get the FCC to "protect" WiFi from "interference". The
>> > current one was Marriott, who requested the FCC for a rule to make it
legal
>> > to disrupt and block use of WiFi in people's rooms in their hotels,
except
>> > with their access points. This also needs some technical defense. I
>> > believe any issues with WiFi performance in actual Marriott hotels are
due
>> > to bufferbloat in their hotel-wide systems, just as the issues with
GoGo are
>> > the same. But it's possible that queueing problems in their own WiFi
gear
>> > are bad as well.
>> >
>> >
>> >
>> > I mention this because it is related, and to the layperson, or
>> > non-radio-knowledgeable executive, indistinguishable. It will take
away the
>> > incentive to actually fix the 802.11 implementations to be better
>> > performing, making the problem seem to be a "management" issue that
can be
>> > solved by making WiFi less interoperable and less flexible by rules,
rather
>> > than by engineering.
>> >
>> >
>> >
>> > However, solving the problems of hotspot networks and hotel networks
are
>> > definitely "real world" issues, and quite along the same lines you
mention,
>> > Dave. FQ is almost certainly a big deal both in WiFi and in the
>> > distribution networks behind WiFi. Co-existence is also a big deal
>> > (RTS/CTS-like mechanisms can go a long way to remediate hidden-terminal
>> > disruption of the basic protocols). Roaming and scaling need work as
well.
>> >
>> >
>> >
>> > It would even be a good thing to invent pragmatic ways to provide "low
rate"
>> > subnets and "high rate" subnets that can coexist, so that
compatibility with
>> > ancient "b" networks need not be maintained on all nets, at great cost
-
>> > just send beacons at a high rate, so that the "b" NICs can't see
them....
>> > but you need pragmatic stack implementations.
>> >
>> >
>> >
>> > But the engineering is not the only challenge. The other challenge is
to
>> > take the initiative and get stuff deployed. In the case of
bufferbloat, the
>> > grade currently is a "D" for deployments, maybe a "D-". Beautiful
technical
>> > work, but the economic/business/political side of things has been poor.
>> > Look at how slow IETF has been to achieve anything (the perfect is
truly the
>> > enemy of the good, and Dave Clark's "rough consensus and working code"
has
>> > been replaced by technocratic malaise, and what appears to me to be a
class
>> > of people who love traveling the world to a floating cocktail party
without
>> > getting anything important done).
>> >
>> >
>> >
>> > The problem with communications is that you can't just ship a product
with a
>> > new "feature", because the innovation only works if widely adopted.
Since
>> > there is no "Linux Desktop" (and Linus hates the idea, to a large
extent)
>> > Linux can't be the sole carrier of the idea. You pretty much need iOS
and
>> > Android both to buy in or to provide a path for easy third-party
upgrades.
>> > How do you do that? Well, that's where the WHATML-type approach is
>> > necessary.
>> >
>> >
>> >
>> > I don't know if this can be achieved, and there are lots of details to
be
>> > worked out. But I'll play.
I'll play.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Saturday, January 31, 2015 4:05pm, "Dave Taht" <dave.taht@gmail.com>
>> > said:
>> >
>> > I would like to have somehow assembled all the focused resources to
make a
>> > go at fixing wifi, or at least having a f2f with a bunch of people in
the
>> > late march timeframe. This message of mine to linux-wireless bounced
for
>> > some reason and I am off to log out for 10 days, so...
>> > see relevant netdev thread also for ore details.
>> >
>> > ---------- Forwarded message ----------
>> > From: Dave Taht <dave.taht@gmail.com>
>> > Date: Sat, Jan 31, 2015 at 12:29 PM
>> > Subject: Re: Throughput regression with `tcp: refine TSO autosizing`
>> > To: Arend van Spriel <arend@broadcom.com>
>> > Cc: linux-wireless <linux-wireless@vger.kernel.org>, Michal Kazior
>> > <michal.kazior@tieto.com>, Eyal Perry <eyalpe@dev.mellanox.co.il>,
Network
>> > Development <netdev@vger.kernel.org>, Eric Dumazet <
eric.dumazet@gmail.com>
>> >
>> >
>> > The wifi industry as a whole has vastly bigger problems than achieving
>> > 1500Mbits in a faraday cage on a single flow.
>> >
>> > I encourage you to try tests in netperf-wrapper that explicitly test
for
>> > latency under load, and in particular, the RTT_FAIR tests against 4 or
more
>> > stations on a single wifi AP. You will find the results very
depressing.
>> > Similarly, on your previous test series, a latency figure would have
been
>> > nice to have. I just did a talk at nznog, where I tested the local
wifi with
>> > less than ambits of throughput, and 3 seconds of latency, filmed here:
>> >
>> > https://plus.google.com/u/0/107942175615993706558/posts/CY8ew8MPnMt
>> >
>> > Do wish more folk were testing in the busy real world environments,
like
>> > coffee shops, cities... really, anywhere outside a faraday cage!
>> >
>> > I am not attending netconf - I was unable to raise funds to go, and the
>> > program committee wanted something "new",
>> >
>> > instead of the preso I gave the IEEE 802.11 working group back in
september.
>> > (
>> >
http://snapon.lab.bufferbloat.net/~d/ieee802.11-sept-17-2014/11-14-1265-00-0wng-More-on-Bufferbloat.pdf
>> > )
>> >
>> > I was very pleased with the results of that talk - the day after I
gave it,
>> > the phrase "test for latency" showed up in a bunch of 802.11ax (the
next
>> > generation after ac) documents. :) Still, we are stuck with the train
wreck
>> > that is 802.11ac glommed on top of 802.11n, glommed on top of 802.11g,
in
>> > terms of queue management, terrible uses of airtime, rate control and
other
>> > stuff. Aruba and Meraki, in particular took a big interest in what I'd
>> > outlined in the preso above (we have a half dozen less well baked
ideas -
>> > that's just the easy stuff that can be done to improve wifi). I gave a
>> > followup at meraki but I don't think that's online.
>> >
>> > Felix (nbd) is on vacation right now, as I am I. In fact I am going
>> > somewhere for a week totally lacking internet access.
>> >
>> > Presently the plan, with what budget (none) we have and time (very
little)
>> > we have is to produce a pair of proof of concept implementations for
per tid
>> > queuing (see relevant commit by nbd), leveraging the new minstrel
stats,
>> > the new minstrel-blues stuff, and an aggregation aware codel with a
>> > calculated target based on the most recently active stations, and a
bunch of
>> > the other stuff outlined above at IEEE.
>> >
>> > It is my hope that this will start to provide accurate back pressure
(or
>> > sufficient lack thereof for TSQ), to also improve throughput while
still
>> > retaining low latency. But it is a certainty that we will run into more
>> > cross layer issues that will be a pita to resolve.
>> >
>> > If we can put together a meet up around or during ELC in california in
>> > march?
>> >
>> > I am really not terribly optimistic on anything other than the 2
chipsets we
>> > can hack on (ath9k, mt76). Negotiations to get qualcomm to open up
their
>> > ath10k firmware have thus far failed, nor has a ath10k-lite got
anywhere.
>> > Perhaps broadcom would be willing to open up their firmware
sufficiently to
>> > build in a better API?
>> >
>> > A bit more below.
>> >
>> >
>> > On Jan 30, 2015 5:59 AM, "Arend van Spriel" <arend@broadcom.com> wrote:
>> >>
>> >> On 01/30/15 14:19, Eric Dumazet wrote:
>> >>>
>> >>> On Fri, 2015-01-30 at 11:29 +0100, Arend van Spriel wrote:
>> >>>
>> >>>> Hi Eric,
>> >>>>
>> >>>> Your suggestions are still based on the fact that you consider
wireless
>> >>>> networking to be similar to ethernet, but as Michal indicated there
are
>> >>>> some fundamental differences starting with CSMA/CD versus CSMA/CA.
Also
>> >>>> the medium conditions are far from comparable.
>> >
>> > The analogy i now use for it is that switched ethernet is generally
your
>> > classic "dumbbell"
>> >
>> > topology. Wifi is more like a "taxi-stand" topology. If you think
about how
>> > people
>> >
>> > queue up at a taxi stand (and sometimes agree to share a ride), the
inter
>> > arrival
>> >
>> > and departure times of a taxi stand make for a better mental model.
>> >
>> > Admittedly, I seem to spend a lot of time, waiting for taxies, thinking
>> > about
>> >
>> > wifi.
>> >
>> >>> There is no shielding so
>> >>>> it needs to deal with interference and dynamically drops the link
rate
>> >>>> so transmission of packets can take several milliseconds. Then with
11n
>> >>>> they came up with aggregation with sends up to 64 packets in a
single
>> >>>> transmit over the air at worst case 6.5 Mbps (if I am not
mistaken). The
>> >>>> parameter value for tcp_limit_output_bytes of 131072 means that it
>> >>>> allows queuing for about 1ms on a 1Gbps link, but I hope you can see
>> >>>> this is not realistic for dealing with all variances of the wireless
>> >>>> medium/standard. I suggested this as topic for the wireless
workshop in
>> >>>> Otawa [1], but I can not attend there. Still hope that there will be
>> >>>> some discussions to get more awareness.
>> >
>> > I have sometimes hoped that TSQ could be made more a function of the
>> >
>> > number of active flows exiting an interface, but eric tells me that's
>> > impossible.
>> >
>> > This is possibly another case where TSQ could use to be a callback
>> > function...
>> >
>> > but frankly I care not a whit about maximizing single flow tcp
throughput on
>> > wifi
>> >
>> > in a faraday cage.
>> >
>> >
>> >>>
>> >>> Ever heard about bufferbloat ?
>> >>
>> >>
>> >> Sure. I am trying to get awareness about that in our wireless
>> >> driver/firmware development teams. So bear with me.
>> >>
>> >>
>> >>> Have you read my suggestions and tried them ?
>> >>>
>> >>> You can adjust the limit per flow to pretty much you want. If you
need
>> >>> 64 packets, just do the math. If in 2018 you need 128 packets, do the
>> >>> math again.
>> >>>
>> >>> I am very well aware that wireless wants aggregation, thank you.
>> >
>> > I note that a lot of people testing this are getting it backwards.
Usually
>> > it is the AP that is sending lots and lots of big packets, where the
return
>> > path is predominately acks from the station.
>> >
>> > I am not a huge fan of stretch acks, but certainly a little bit of
thinning
>> > doesn't bother me on the return path there.
>> >
>> > Going the other way, particularly in a wifi world that insists on
treating
>> > every packet as sacred (which I don't agree with at all), thinning
acks can
>> > help, but single stream throughput is of interest only on benchmarks,
FQing
>> > as much as possible all the flows destined the station in each
aggregate
>> > masks loss and reduces the need to protect everything so much.
>> >
>> >>
>> >> Sorry if I offended you. I was just giving these as example combined
with
>> >> effective rate usable on the medium to say that the bandwidth is more
>> >> dynamic in wireless and as such need dynamic change of queue depth.
Now this
>> >> can be done by making the fraction size as used in your suggestion
adaptive
>> >> to these conditions.
>> >
>> > Well... see above. Maybe this technique will do more of the right
thing,
>> > but... go test.
>> >
>> >
>> >>
>> >>> 131072 bytes of queue on 40Gbit is not 1ms, but 26 usec of queueing,
and
>> >>> we get line rate nevertheless.
>> >>
>> >>
>> >> I was saying it was about 1ms on *1Gbit* as the wireless TCP rates are
>> >> moving into that direction in 11ac.
>> >>
>> >>
>> >>> We need this level of shallow queues (BQL, TSQ), to get very precise
rtt
>> >>> estimations so that TCP has good entropy for its pacing, even in the
50
>> >>> usec rtt ranges.
>> >>>
>> >>> If we allowed 1ms of queueing, then a 40Gbit flow would queue 5
MBytes.
>> >>>
>> >>> This was terrible, because it increased cwnd and all sender queues to
>> >>> insane levels.
>> >>
>> >>
>> >> Indeed and that is what we would like to address in our wireless
drivers.
>> >> I will setup some experiments using the fraction sizing and post my
>> >> findings. Again sorry if I offended you.
>> >
>> > You really, really, really need to test at rates below 50mbit and with
other
>> > stations, also while doing this. It's not going to be a linear curve.
>> >
>> >
>> >
>> >>
>> >> Regards,
>> >> Arend
>> >>
>> >> --
>> >> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> >> the body of a message to majordomo@vger.kernel.org
>> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> >
>> >
>> >
>> > --
>> > Dave Täht
>> >
>> > thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
>
>
[-- Attachment #1.2: Type: text/html, Size: 27633 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [PATCH v2 3/3] netlabel: Less function calls in netlbl_mgmt_add_common() after error detection
From: SF Markus Elfring @ 2015-02-01 10:15 UTC (permalink / raw)
To: Paul Moore; +Cc: David S. Miller, netdev, LKML, kernel-janitors, Julia Lawall
In-Reply-To: <CAHC9VhQ5C32zRqG0emVUoMmuvBsV+TXvdNn+54iVyCPBNk9dDQ@mail.gmail.com>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 1 Feb 2015 11:11:29 +0100
The functions "cipso_v4_doi_putdef" and "kfree" could be called in some cases
by the netlbl_mgmt_add_common() function during error handling even if the
passed variables contained still a null pointer.
* This implementation detail could be improved by adjustments for jump labels.
* Let us return immediately after the first failed function call according to
the current Linux coding style convention.
* Let us delete also an unnecessary check for the variable "entry" there.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
net/netlabel/netlabel_mgmt.c | 49 ++++++++++++++++++++++----------------------
1 file changed, 24 insertions(+), 25 deletions(-)
diff --git a/net/netlabel/netlabel_mgmt.c b/net/netlabel/netlabel_mgmt.c
index f5807f5..7044074 100644
--- a/net/netlabel/netlabel_mgmt.c
+++ b/net/netlabel/netlabel_mgmt.c
@@ -93,23 +93,20 @@ static int netlbl_mgmt_add_common(struct genl_info *info,
struct netlbl_audit *audit_info)
{
int ret_val = -EINVAL;
- struct netlbl_dom_map *entry = NULL;
struct netlbl_domaddr_map *addrmap = NULL;
struct cipso_v4_doi *cipsov4 = NULL;
u32 tmp_val;
+ struct netlbl_dom_map *entry = kzalloc(sizeof(*entry), GFP_KERNEL);
- entry = kzalloc(sizeof(*entry), GFP_KERNEL);
- if (entry == NULL) {
- ret_val = -ENOMEM;
- goto add_failure;
- }
+ if (!entry)
+ return -ENOMEM;
entry->def.type = nla_get_u32(info->attrs[NLBL_MGMT_A_PROTOCOL]);
if (info->attrs[NLBL_MGMT_A_DOMAIN]) {
size_t tmp_size = nla_len(info->attrs[NLBL_MGMT_A_DOMAIN]);
entry->domain = kmalloc(tmp_size, GFP_KERNEL);
if (entry->domain == NULL) {
ret_val = -ENOMEM;
- goto add_failure;
+ goto add_free_entry;
}
nla_strlcpy(entry->domain,
info->attrs[NLBL_MGMT_A_DOMAIN], tmp_size);
@@ -125,16 +122,16 @@ static int netlbl_mgmt_add_common(struct genl_info *info,
break;
case NETLBL_NLTYPE_CIPSOV4:
if (!info->attrs[NLBL_MGMT_A_CV4DOI])
- goto add_failure;
+ goto add_free_domain;
tmp_val = nla_get_u32(info->attrs[NLBL_MGMT_A_CV4DOI]);
cipsov4 = cipso_v4_doi_getdef(tmp_val);
if (cipsov4 == NULL)
- goto add_failure;
+ goto add_free_domain;
entry->def.cipso = cipsov4;
break;
default:
- goto add_failure;
+ goto add_free_domain;
}
if (info->attrs[NLBL_MGMT_A_IPV4ADDR]) {
@@ -145,7 +142,7 @@ static int netlbl_mgmt_add_common(struct genl_info *info,
addrmap = kzalloc(sizeof(*addrmap), GFP_KERNEL);
if (addrmap == NULL) {
ret_val = -ENOMEM;
- goto add_failure;
+ goto add_doi_put_def;
}
INIT_LIST_HEAD(&addrmap->list4);
INIT_LIST_HEAD(&addrmap->list6);
@@ -153,12 +150,12 @@ static int netlbl_mgmt_add_common(struct genl_info *info,
if (nla_len(info->attrs[NLBL_MGMT_A_IPV4ADDR]) !=
sizeof(struct in_addr)) {
ret_val = -EINVAL;
- goto add_failure;
+ goto add_free_addrmap;
}
if (nla_len(info->attrs[NLBL_MGMT_A_IPV4MASK]) !=
sizeof(struct in_addr)) {
ret_val = -EINVAL;
- goto add_failure;
+ goto add_free_addrmap;
}
addr = nla_data(info->attrs[NLBL_MGMT_A_IPV4ADDR]);
mask = nla_data(info->attrs[NLBL_MGMT_A_IPV4MASK]);
@@ -166,7 +163,7 @@ static int netlbl_mgmt_add_common(struct genl_info *info,
map = kzalloc(sizeof(*map), GFP_KERNEL);
if (map == NULL) {
ret_val = -ENOMEM;
- goto add_failure;
+ goto add_free_addrmap;
}
map->list.addr = addr->s_addr & mask->s_addr;
map->list.mask = mask->s_addr;
@@ -178,7 +175,7 @@ static int netlbl_mgmt_add_common(struct genl_info *info,
ret_val = netlbl_af4list_add(&map->list, &addrmap->list4);
if (ret_val != 0) {
kfree(map);
- goto add_failure;
+ goto add_free_addrmap;
}
entry->def.type = NETLBL_NLTYPE_ADDRSELECT;
@@ -192,7 +189,7 @@ static int netlbl_mgmt_add_common(struct genl_info *info,
addrmap = kzalloc(sizeof(*addrmap), GFP_KERNEL);
if (addrmap == NULL) {
ret_val = -ENOMEM;
- goto add_failure;
+ goto add_doi_put_def;
}
INIT_LIST_HEAD(&addrmap->list4);
INIT_LIST_HEAD(&addrmap->list6);
@@ -200,12 +197,12 @@ static int netlbl_mgmt_add_common(struct genl_info *info,
if (nla_len(info->attrs[NLBL_MGMT_A_IPV6ADDR]) !=
sizeof(struct in6_addr)) {
ret_val = -EINVAL;
- goto add_failure;
+ goto add_free_addrmap;
}
if (nla_len(info->attrs[NLBL_MGMT_A_IPV6MASK]) !=
sizeof(struct in6_addr)) {
ret_val = -EINVAL;
- goto add_failure;
+ goto add_free_addrmap;
}
addr = nla_data(info->attrs[NLBL_MGMT_A_IPV6ADDR]);
mask = nla_data(info->attrs[NLBL_MGMT_A_IPV6MASK]);
@@ -213,7 +210,7 @@ static int netlbl_mgmt_add_common(struct genl_info *info,
map = kzalloc(sizeof(*map), GFP_KERNEL);
if (map == NULL) {
ret_val = -ENOMEM;
- goto add_failure;
+ goto add_free_addrmap;
}
map->list.addr = *addr;
map->list.addr.s6_addr32[0] &= mask->s6_addr32[0];
@@ -227,7 +224,7 @@ static int netlbl_mgmt_add_common(struct genl_info *info,
ret_val = netlbl_af6list_add(&map->list, &addrmap->list6);
if (ret_val != 0) {
kfree(map);
- goto add_failure;
+ goto add_free_addrmap;
}
entry->def.type = NETLBL_NLTYPE_ADDRSELECT;
@@ -237,15 +234,17 @@ static int netlbl_mgmt_add_common(struct genl_info *info,
ret_val = netlbl_domhsh_add(entry, audit_info);
if (ret_val != 0)
- goto add_failure;
+ goto add_free_addrmap;
return 0;
-add_failure:
- cipso_v4_doi_putdef(cipsov4);
- if (entry)
- kfree(entry->domain);
+add_free_addrmap:
kfree(addrmap);
+add_doi_put_def:
+ cipso_v4_doi_putdef(cipsov4);
+add_free_domain:
+ kfree(entry->domain);
+add_free_entry:
kfree(entry);
return ret_val;
}
--
2.2.2
^ permalink raw reply related
* Re: Fwd: Throughput regression with `tcp: refine TSO autosizing`
From: Jonathan Morton @ 2015-02-01 10:47 UTC (permalink / raw)
To: Dave Taht
Cc: dstanley, Andrew McGregor, Stig Thormodsrud, netdev,
linux-wireless, Jesper Dangaard Brouer, cerowrt-devel,
Matt Mathis, Derrick Pallas, Mahesh Paolini-Subramanya,
Kathy Giori, Tim Shepard, Avery Pennarun
In-Reply-To: <CAA93jw7=oTex0Mp-0ThvuDRUnfR0N8tzdOQ8DD7QYWphp1b=4w@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2975 bytes --]
Since this is going to be a big job, it's worth prioritising parts of it
appropriately.
Minstrel is probably already the single best feature of the Linux Wi-Fi
stack. AFAIK it still outperforms any other rate selector we know about. So
I don't consider improving it further to be a high priority, although that
trick of using it as a sneaky random packet loss inducer is intriguing.
Much more important and urgent is getting some form of functioning SQM
closer to the hardware, where the information is. I don't think we need to
get super fancy here to do some real good, in the same way that PIE is a
major improvement over drop-tail. I'd settle for a variant of fq_codel that
gets and uses information about whether the current packet request might be
aggregated with the previous packet provided, and adjusts its choice of
packet accordingly.
At the same time, models would undoubtedly be useful to help test and
repeatably demonstrate the advantages of both simple and more sophisticated
solutions. Ns3 allows laying out a reasonably complex radio environment,
which is great for this. To counter the prevalence of one-station Faraday
cage tests in the industry, the simulated environments should represent
realistic, challenging use cases:
1) the family home, with half a dozen client devices competing with several
interference sources (Bluetooth, RC toys, microwave oven, etc). This is a
relatively easy environment, representing the expected environment for
consumer equipment.
2) the apartment block, with fewer clients per AP but lots of APs
distributed throughout a large building. Walls and floors may provide
valuable attenuation here - unless you're in Japan, where they can be
notoriously thin.
3) the railway carriage, consisting of eighty passengers in a 20x3 m space,
and roughly the same number of client devices. The uplink is 3G based and
has some inherent latency. Add some Bluetooth for flavour, stir gently.
This one is rather challenging, but there is scope to optimise AP antenna
placement, and to scale the test down slightly by reducing seat occupancy.
4) the jumbo jet, consisting of several hundred passengers crammed in like
sardines. The uplink has satellite latencies built in. Good luck.
5) the business hotel. Multiple APs will be needed to provide adequate
coverage for this environment, which should encompass the rooms as well as
lounge, conference and dining areas. Some visitors may bring their own APs,
and the system must be able to cope with this without seriously degrading
performance.
6) the trade conference. A large arena filled with thousands of people.
Multiple APs required. Good luck.
I also feel that ultimately we're going to have to get industry on board.
Not just passively letting us play around as with ath9k, but actively
taking note of our findings and implementing at least a few of our ideas
themselves. Of course, tools, models and real-world results are likely to
make that easier.
- Jonathan Morton
[-- Attachment #1.2: Type: text/html, Size: 3211 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH] tun: orphan an skb on tx
From: David Woodhouse @ 2015-02-01 11:20 UTC (permalink / raw)
To: Herbert Xu
Cc: Eric Dumazet, Michael S. Tsirkin, Jan Kiszka, David S. Miller,
Paul Moore, netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
qemu-devel
In-Reply-To: <20100414005822.GD18044@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 1663 bytes --]
On Wed, 2010-04-14 at 08:58 +0800, Herbert Xu wrote:
> On Tue, Apr 13, 2010 at 08:31:03PM +0200, Eric Dumazet wrote:
> >
> > Herbert Acked your patch, so I guess its OK, but I think it can be
> > dangerous.
>
> The tun socket accounting was never designed to stop it from
> flooding another tun interface. It's there to stop it from
> transmitting above a destination interface TX bandwidth and
> cause unnecessary packet drops. It also limits the total amount
> of kernel memory that can be pinned down by a single tun interface.
>
> In this case, all we're doing is shifting the accounting from the
> "hardware" queue to the qdisc queue.
>
> So your ability to flood a tun interface is essentially unchanged.
I've just been looking at VPN performance, using netperf to flood an
openconnect/ocserv connection over GigE and profiling my VPN client.
If I run netperf over the *unencrypted* link, it only sends 1Gb/s of
packets — because the packets are correctly accounted to netperf's UDP
socket until the moment they're actually transmitted on the wire, and
the backpressure works correctly.
When I run over the VPN, netperf thinks it sent 2½ times the amount of
TX traffic. Packets are being dropped by the tun device before even
feeding them up to the VPN client to be sent — presumably because of
this skb_orphan() call. (The client itself should do the right thing,
and only suck packets out of the tun at the rate it can shove them out
*its* UDP socket.)
Did we ever look at the alternative solution of taking ownership only
after a timeout, or on demand when we need to shut down the device?
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]
^ permalink raw reply
* [PATCH for-next 00/11] Add network namespace support in the RDMA-CM
From: Shachar Raindel @ 2015-02-01 11:28 UTC (permalink / raw)
To: roland-DgEjT+Ai2ygdnm+yROfE0A, sean.hefty-ral2JQCrhuEAvxtiuMwx3w
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
liranl-VPRAkNaXOzVWk0Htik3J/w, Shachar Raindel
RDMA-CM uses IP based addressing and routing to setup RDMA connections between
hosts. Currently, all of the IP interfaces and addresses used by the RDMA-CM
must reside in the init_net namespace. This restricts the usage of containers
with RDMA to only work with host network namespace (aka the kernel init_net NS
instance).
This patchset allows using network namespaces with the RDMA-CM.
Each RDMA-CM and CM id is keeping a reference to a network namespace.
This reference is based on the process network namespace at the time of the
creation of the object or inherited from the listener.
This network namespace is used to perform all IP and network related
operations. Specifically, the local device lookup, as well as the remote GID
address resolution are done in the context of the RDMA-CM object's namespace.
This allows outgoing connections to reach the right target, even if the same
IP address exists in multiple network namespaces. This can happen if each
network namespace resides on a different pkey.
Additionally, the network namespace is used to split the listener service ID
table. From the user point of view, each network namespace has a unique,
completely independent table of service IDs. This allows running multiple
instances of a single service on the same machine, using containers. To
implement this, the CM layer now parses the IP address from the CM connect
requests, and searches for the matching networking device. The namespace of
the device found is used when looking up the service ID in the listener table.
The functionnality introduced by this series would come into play when the
transport is InfiniBand and IPoIB interfaces are assigned to each namespace.
Multiple IPoIB interfaces can be created and assigned to different RDMA-CM
capable containers, for example using pipework [1].
Full support for RoCE will be introduced in a later stage.
The patches apply against kernel v3.19-rc5, with the patch "RDMA/CMA: Mark
IPv4 addresses correctly when the listener is IPv6" [2] applied.
The patchset is structured as follows:
Patches 1 and 2 are relatively trivial API extensions, requiring the callers
of certain ib_addr and ib_core functions to provide a network namespace, as
needed.
Patches 3 and 4 adds the ability to lookup a network namespace according to
the IP address, device and pkey. It finds the matching IPoIB interfaces, and
safely takes a reference on the network namespace before returning to the
caller.
Patch 5 moves the logic that extracts the IP address from a connect request
into the CM layer. This is needed for the upcoming listener lookup by
namespace.
Patch 6 adds support for network namespaces in the CM layer. All callers are
still passing init_net as the namespace, to maintain backward compatibility.
For incoming requests, the namespace of the relevant IPoIB device is used.
Patches 7 and 8 add proper namespace support to the RDMA-CM module.
Patches 9 and 10 add namespace support to the relevant user facing modules in
the IB stack.
[1] https://github.com/jpetazzo/pipework/pull/108
[2] https://patchwork.kernel.org/patch/5298971/
Guy Shapiro (7):
IB/addr: Pass network namespace as a parameter
IB/core: Pass network namespace as a parameter to relevant functions
IB/ipoib: Return IPoIB devices as possible matches to
get_net_device_by_port_pkey_ip
IB/cm,cma: Move RDMA IP CM private-data parsing code from ib_cma to
ib_cm
IB/cm: Add network namespace support
IB/cma: Add support for network namespaces
IB/ucma: Take the network namespace from the process
Shachar Raindel (1):
IB/ucm: Add partial support for network namespaces
Yotam Kenneth (2):
IB/core: Find the network namespace matching connection parameters
IB/cma: Separate port allocation to network namespaces
drivers/infiniband/core/addr.c | 31 +-
drivers/infiniband/core/agent.c | 4 +-
drivers/infiniband/core/cm.c | 298 ++++++++++++++++--
drivers/infiniband/core/cma.c | 332 +++++++++------------
drivers/infiniband/core/device.c | 57 ++++
drivers/infiniband/core/mad_rmpp.c | 10 +-
drivers/infiniband/core/ucm.c | 4 +-
drivers/infiniband/core/ucma.c | 4 +-
drivers/infiniband/core/user_mad.c | 4 +-
drivers/infiniband/core/verbs.c | 22 +-
drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 3 +-
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 21 +-
drivers/infiniband/ulp/ipoib/ipoib_main.c | 122 +++++++-
drivers/infiniband/ulp/iser/iser_verbs.c | 2 +-
drivers/infiniband/ulp/isert/ib_isert.c | 2 +-
drivers/infiniband/ulp/srp/ib_srp.c | 2 +-
drivers/infiniband/ulp/srpt/ib_srpt.c | 5 +-
.../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h | 4 +-
include/rdma/ib_addr.h | 44 ++-
include/rdma/ib_cm.h | 53 +++-
include/rdma/ib_verbs.h | 44 ++-
include/rdma/rdma_cm.h | 6 +-
net/9p/trans_rdma.c | 2 +-
net/rds/ib.c | 2 +-
net/rds/ib_cm.c | 2 +-
net/rds/iw.c | 2 +-
net/rds/iw_cm.c | 2 +-
net/rds/rdma_transport.c | 2 +-
net/sunrpc/xprtrdma/svc_rdma_transport.c | 2 +-
net/sunrpc/xprtrdma/verbs.c | 3 +-
30 files changed, 823 insertions(+), 268 deletions(-)
--
1.7.11.2
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH for-next 02/10] IB/core: Pass network namespace as a parameter to relevant functions
From: Shachar Raindel @ 2015-02-01 11:28 UTC (permalink / raw)
To: roland-DgEjT+Ai2ygdnm+yROfE0A, sean.hefty-ral2JQCrhuEAvxtiuMwx3w
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
liranl-VPRAkNaXOzVWk0Htik3J/w, Guy Shapiro, Haggai Eran,
Yotam Kenneth, Shachar Raindel
In-Reply-To: <1422790133-28725-1-git-send-email-raindel-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
From: Guy Shapiro <guysh-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Add network namespace parameters for the address related ib_core
functions. The parameter is passed to lower level function, instead of
&init_net, so things are done in the correct namespace.
For now pass &init_net on every caller.
Callers that will pass &init_net permanently are marked with an
appropriate comment.
Signed-off-by: Haggai Eran <haggaie-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Yotam Kenneth <yotamke-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Shachar Raindel <raindel-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Guy Shapiro <guysh-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
drivers/infiniband/core/agent.c | 4 +++-
drivers/infiniband/core/cm.c | 9 +++++++--
drivers/infiniband/core/mad_rmpp.c | 10 ++++++++--
drivers/infiniband/core/user_mad.c | 4 +++-
drivers/infiniband/core/verbs.c | 10 ++++++----
drivers/infiniband/ulp/srpt/ib_srpt.c | 3 ++-
include/rdma/ib_verbs.h | 15 +++++++++++++--
7 files changed, 42 insertions(+), 13 deletions(-)
diff --git a/drivers/infiniband/core/agent.c b/drivers/infiniband/core/agent.c
index f6d29614cb01..539378d64041 100644
--- a/drivers/infiniband/core/agent.c
+++ b/drivers/infiniband/core/agent.c
@@ -99,7 +99,9 @@ void agent_send_response(struct ib_mad *mad, struct ib_grh *grh,
}
agent = port_priv->agent[qpn];
- ah = ib_create_ah_from_wc(agent->qp->pd, wc, grh, port_num);
+ /* Physical devices (and their MAD replies) always reside in the host
+ * network namespace */
+ ah = ib_create_ah_from_wc(agent->qp->pd, wc, grh, port_num, &init_net);
if (IS_ERR(ah)) {
dev_err(&device->dev, "ib_create_ah_from_wc error %ld\n",
PTR_ERR(ah));
diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
index e28a494e2a3a..5a45cb76c43e 100644
--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -290,8 +290,13 @@ static int cm_alloc_response_msg(struct cm_port *port,
struct ib_mad_send_buf *m;
struct ib_ah *ah;
+ /* For IB, the network namespace doesn't affect the created address
+ * handle, so we use &init_net. In the future, RoCE support will
+ * require finding a specific network namespace to send the response
+ * from. */
ah = ib_create_ah_from_wc(port->mad_agent->qp->pd, mad_recv_wc->wc,
- mad_recv_wc->recv_buf.grh, port->port_num);
+ mad_recv_wc->recv_buf.grh, port->port_num,
+ &init_net);
if (IS_ERR(ah))
return PTR_ERR(ah);
@@ -346,7 +351,7 @@ static void cm_init_av_for_response(struct cm_port *port, struct ib_wc *wc,
av->port = port;
av->pkey_index = wc->pkey_index;
ib_init_ah_from_wc(port->cm_dev->ib_device, port->port_num, wc,
- grh, &av->ah_attr);
+ grh, &av->ah_attr, &init_net);
}
static int cm_init_av_by_path(struct ib_sa_path_rec *path, struct cm_av *av)
diff --git a/drivers/infiniband/core/mad_rmpp.c b/drivers/infiniband/core/mad_rmpp.c
index f37878c9c06e..6c1576202965 100644
--- a/drivers/infiniband/core/mad_rmpp.c
+++ b/drivers/infiniband/core/mad_rmpp.c
@@ -157,8 +157,11 @@ static struct ib_mad_send_buf *alloc_response_msg(struct ib_mad_agent *agent,
struct ib_ah *ah;
int hdr_len;
+ /* Physical devices (and their MAD replies) always reside in the host
+ * network namespace */
ah = ib_create_ah_from_wc(agent->qp->pd, recv_wc->wc,
- recv_wc->recv_buf.grh, agent->port_num);
+ recv_wc->recv_buf.grh, agent->port_num,
+ &init_net);
if (IS_ERR(ah))
return (void *) ah;
@@ -287,10 +290,13 @@ create_rmpp_recv(struct ib_mad_agent_private *agent,
if (!rmpp_recv)
return NULL;
+ /* Physical devices (and their MAD replies) always reside in the host
+ * network namespace */
rmpp_recv->ah = ib_create_ah_from_wc(agent->agent.qp->pd,
mad_recv_wc->wc,
mad_recv_wc->recv_buf.grh,
- agent->agent.port_num);
+ agent->agent.port_num,
+ &init_net);
if (IS_ERR(rmpp_recv->ah))
goto error;
diff --git a/drivers/infiniband/core/user_mad.c b/drivers/infiniband/core/user_mad.c
index 928cdd20e2d1..f34c6077759d 100644
--- a/drivers/infiniband/core/user_mad.c
+++ b/drivers/infiniband/core/user_mad.c
@@ -239,7 +239,9 @@ static void recv_handler(struct ib_mad_agent *agent,
ib_init_ah_from_wc(agent->device, agent->port_num,
mad_recv_wc->wc, mad_recv_wc->recv_buf.grh,
- &ah_attr);
+ &ah_attr, &init_net);
+ /* Note that network namespace seperation isn't supported on
+ * umad yet. */
packet->mad.hdr.gid_index = ah_attr.grh.sgid_index;
packet->mad.hdr.hop_limit = ah_attr.grh.hop_limit;
diff --git a/drivers/infiniband/core/verbs.c b/drivers/infiniband/core/verbs.c
index ca5c4dd8a67a..a51d5d642fb7 100644
--- a/drivers/infiniband/core/verbs.c
+++ b/drivers/infiniband/core/verbs.c
@@ -193,7 +193,8 @@ struct ib_ah *ib_create_ah(struct ib_pd *pd, struct ib_ah_attr *ah_attr)
EXPORT_SYMBOL(ib_create_ah);
int ib_init_ah_from_wc(struct ib_device *device, u8 port_num, struct ib_wc *wc,
- struct ib_grh *grh, struct ib_ah_attr *ah_attr)
+ struct ib_grh *grh, struct ib_ah_attr *ah_attr,
+ struct net *net)
{
u32 flow_class;
u16 gid_index;
@@ -214,7 +215,7 @@ int ib_init_ah_from_wc(struct ib_device *device, u8 port_num, struct ib_wc *wc,
ret = rdma_addr_find_dmac_by_grh(&grh->dgid, &grh->sgid,
ah_attr->dmac,
&ah_attr->vlan_id,
- &init_net);
+ net);
if (ret)
return ret;
}
@@ -247,12 +248,13 @@ int ib_init_ah_from_wc(struct ib_device *device, u8 port_num, struct ib_wc *wc,
EXPORT_SYMBOL(ib_init_ah_from_wc);
struct ib_ah *ib_create_ah_from_wc(struct ib_pd *pd, struct ib_wc *wc,
- struct ib_grh *grh, u8 port_num)
+ struct ib_grh *grh, u8 port_num,
+ struct net *net)
{
struct ib_ah_attr ah_attr;
int ret;
- ret = ib_init_ah_from_wc(pd->device, port_num, wc, grh, &ah_attr);
+ ret = ib_init_ah_from_wc(pd->device, port_num, wc, grh, &ah_attr, net);
if (ret)
return ERR_PTR(ret);
diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c
index eb694ddad79f..7867bd554027 100644
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
@@ -468,7 +468,8 @@ static void srpt_mad_recv_handler(struct ib_mad_agent *mad_agent,
return;
ah = ib_create_ah_from_wc(mad_agent->qp->pd, mad_wc->wc,
- mad_wc->recv_buf.grh, mad_agent->port_num);
+ mad_wc->recv_buf.grh, mad_agent->port_num,
+ &init_net);
if (IS_ERR(ah))
goto err;
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 0d74f1de99aa..dd4c80cea8d3 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -48,6 +48,7 @@
#include <linux/rwsem.h>
#include <linux/scatterlist.h>
#include <linux/workqueue.h>
+#include <net/net_namespace.h>
#include <uapi/linux/if_ether.h>
#include <linux/atomic.h>
@@ -1801,9 +1802,14 @@ struct ib_ah *ib_create_ah(struct ib_pd *pd, struct ib_ah_attr *ah_attr);
* ignored unless the work completion indicates that the GRH is valid.
* @ah_attr: Returned attributes that can be used when creating an address
* handle for replying to the message.
+ * @net: The network namespace to use for address resolution.
+ *
+ * It is the caller's responsibility to make sure the network namespace is
+ * alive until the function returns.
*/
int ib_init_ah_from_wc(struct ib_device *device, u8 port_num, struct ib_wc *wc,
- struct ib_grh *grh, struct ib_ah_attr *ah_attr);
+ struct ib_grh *grh, struct ib_ah_attr *ah_attr,
+ struct net *net);
/**
* ib_create_ah_from_wc - Creates an address handle associated with the
@@ -1813,12 +1819,17 @@ int ib_init_ah_from_wc(struct ib_device *device, u8 port_num, struct ib_wc *wc,
* @grh: References the received global route header. This parameter is
* ignored unless the work completion indicates that the GRH is valid.
* @port_num: The outbound port number to associate with the address.
+ * @net: The network namespace to use for address resolution.
*
* The address handle is used to reference a local or global destination
* in all UD QP post sends.
+ *
+ * It is the caller's responsibility to make sure the network namespace is
+ * alive until the function returns.
*/
struct ib_ah *ib_create_ah_from_wc(struct ib_pd *pd, struct ib_wc *wc,
- struct ib_grh *grh, u8 port_num);
+ struct ib_grh *grh, u8 port_num,
+ struct net *net);
/**
* ib_modify_ah - Modifies the address vector associated with an address
--
1.7.11.2
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH for-next 04/10] IB/ipoib: Return IPoIB devices as possible matches to get_net_device_by_port_pkey_ip
From: Shachar Raindel @ 2015-02-01 11:28 UTC (permalink / raw)
To: roland-DgEjT+Ai2ygdnm+yROfE0A, sean.hefty-ral2JQCrhuEAvxtiuMwx3w
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
liranl-VPRAkNaXOzVWk0Htik3J/w, Guy Shapiro, Haggai Eran,
Yotam Kenneth, Shachar Raindel
In-Reply-To: <1422790133-28725-1-git-send-email-raindel-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
From: Guy Shapiro <guysh-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Implement callback that returns network device to ib_core according to
connection parameters. Check the ipoib device and iterate over all child
devices to look for a match.
For each ipoib device we iterate through all upper devices when searching for
a matching IP, in order to support bonding.
Signed-off-by: Guy Shapiro <guysh-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Haggai Eran <haggaie-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Yotam Kenneth <yotamke-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Shachar Raindel <raindel-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
drivers/infiniband/ulp/ipoib/ipoib_main.c | 122 +++++++++++++++++++++++++++++-
1 file changed, 121 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index 6bad17d4d588..88fb78dd68c9 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -48,6 +48,9 @@
#include <linux/jhash.h>
#include <net/arp.h>
+#include <net/addrconf.h>
+#include <linux/inetdevice.h>
+#include <rdma/ib_cache.h>
#define DRV_VERSION "1.0.0"
@@ -91,11 +94,15 @@ struct ib_sa_client ipoib_sa_client;
static void ipoib_add_one(struct ib_device *device);
static void ipoib_remove_one(struct ib_device *device);
static void ipoib_neigh_reclaim(struct rcu_head *rp);
+static struct net_device *ipoib_get_net_device_by_port_pkey_ip(
+ struct ib_device *dev, u8 port, u16 pkey,
+ struct sockaddr *addr);
static struct ib_client ipoib_client = {
.name = "ipoib",
.add = ipoib_add_one,
- .remove = ipoib_remove_one
+ .remove = ipoib_remove_one,
+ .get_net_device_by_port_pkey_ip = ipoib_get_net_device_by_port_pkey_ip,
};
int ipoib_open(struct net_device *dev)
@@ -222,6 +229,119 @@ static int ipoib_change_mtu(struct net_device *dev, int new_mtu)
return 0;
}
+static bool ipoib_is_dev_match_addr(struct sockaddr *addr,
+ struct net_device *dev)
+{
+ struct net *net = dev_net(dev);
+
+ if (addr->sa_family == AF_INET) {
+ struct in_device *in_dev = in_dev_get(dev);
+ struct sockaddr_in *addr_in = (struct sockaddr_in *)addr;
+ __be32 ret_addr;
+
+ if (!in_dev)
+ return false;
+
+ ret_addr = inet_confirm_addr(net, in_dev, 0,
+ addr_in->sin_addr.s_addr,
+ RT_SCOPE_HOST);
+ in_dev_put(in_dev);
+ if (ret_addr)
+ return true;
+ }
+#if IS_ENABLED(CONFIG_IPV6)
+ else if (addr->sa_family == AF_INET6) {
+ struct sockaddr_in6 *addr_in6 = (struct sockaddr_in6 *)addr;
+
+ if (ipv6_chk_addr(net, &addr_in6->sin6_addr, dev, 1))
+ return true;
+ }
+#endif
+ return false;
+}
+
+/**
+ * Find a net_device matching the given address, which is an upper device of
+ * the given net_device.
+ * @addr: IP address to look for.
+ * @dev: base IPoIB net_device
+ *
+ * If found, returns the net_device with a reference held. Otherwise return
+ * NULL.
+ */
+static struct net_device *ipoib_get_net_dev_match_addr(struct sockaddr *addr,
+ struct net_device *dev)
+{
+ struct net_device *upper,
+ *result = NULL;
+ struct list_head *iter;
+
+ if (ipoib_is_dev_match_addr(addr, dev)) {
+ dev_hold(dev);
+ return dev;
+ }
+
+ rcu_read_lock();
+ netdev_for_each_all_upper_dev_rcu(dev, upper, iter) {
+ if (ipoib_is_dev_match_addr(addr, upper)) {
+ dev_hold(upper);
+ result = upper;
+ break;
+ }
+ }
+ rcu_read_unlock();
+ return result;
+}
+
+static struct net_device *ipoib_get_net_device_by_port_pkey_ip(
+ struct ib_device *dev, u8 port, u16 pkey, struct sockaddr *addr)
+{
+ struct ipoib_dev_priv *priv;
+ struct list_head *dev_list;
+ u16 pkey_index;
+
+ ib_find_cached_pkey(dev, port, pkey, &pkey_index);
+ if (pkey_index == (u16)-1)
+ return NULL;
+
+ if (rdma_node_get_transport(dev->node_type) != RDMA_TRANSPORT_IB)
+ return NULL;
+
+ dev_list = ib_get_client_data(dev, &ipoib_client);
+ if (!dev_list)
+ return NULL;
+
+ list_for_each_entry(priv, dev_list, list) {
+ struct net_device *net_dev = NULL;
+ struct ipoib_dev_priv *child_priv;
+
+ if (priv->port != port)
+ continue;
+
+ if (priv->pkey_index == pkey_index) {
+ net_dev = ipoib_get_net_dev_match_addr(addr, priv->dev);
+ if (net_dev)
+ return net_dev;
+ }
+
+ down_read(&priv->vlan_rwsem);
+ list_for_each_entry(child_priv,
+ &priv->child_intfs, list) {
+ if (child_priv->pkey_index != pkey_index)
+ continue;
+
+ net_dev = ipoib_get_net_dev_match_addr(
+ addr, child_priv->dev);
+ if (net_dev)
+ break;
+ }
+ up_read(&priv->vlan_rwsem);
+ if (net_dev)
+ return net_dev;
+ }
+ return NULL;
+}
+
int ipoib_set_mode(struct net_device *dev, const char *buf)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
--
1.7.11.2
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH for-next 05/10] IB/cm,cma: Move RDMA IP CM private-data parsing code from ib_cma to ib_cm
From: Shachar Raindel @ 2015-02-01 11:28 UTC (permalink / raw)
To: roland-DgEjT+Ai2ygdnm+yROfE0A, sean.hefty-ral2JQCrhuEAvxtiuMwx3w
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
liranl-VPRAkNaXOzVWk0Htik3J/w, Guy Shapiro, Haggai Eran,
Yotam Kenneth, Shachar Raindel
In-Reply-To: <1422790133-28725-1-git-send-email-raindel-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
From: Guy Shapiro <guysh-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
When receiving a connection request, ib_cm needs to associate the request with
a network namespace. To do this, it needs to know the request's destination
IP. For this the RDMA IP CM packet formatting functionality needs to be
exposed to ib_cm.
This patch merely moves the RDMA IP CM data formatting and parsing functions
to be part of ib_cm. The following patch will utilize the new knowledge to
look-up the appropriate namespace. Each namespace maintains an independent
table of RDMA CM service IDs, allowing isolation and separation between the
network namespaces.
When creating a new incoming connection ID, the code in cm_save_ip_info can no
longer rely on the listener's private data to find the port number, so it
reads it from the requested service ID. This required saving the service ID in
cm_format_paths_from_req.
Signed-off-by: Guy Shapiro <guysh-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Haggai Eran <haggaie-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Yotam Kenneth <yotamke-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Shachar Raindel <raindel-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
drivers/infiniband/core/cm.c | 167 ++++++++++++++++++++++++++++++++++++++++++
drivers/infiniband/core/cma.c | 166 +++++------------------------------------
include/rdma/ib_cm.h | 46 ++++++++++++
3 files changed, 231 insertions(+), 148 deletions(-)
diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
index 5a45cb76c43e..5cc1a4aa9728 100644
--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -51,6 +51,7 @@
#include <rdma/ib_cache.h>
#include <rdma/ib_cm.h>
+#include <rdma/ib.h>
#include "cm_msgs.h"
MODULE_AUTHOR("Sean Hefty");
@@ -701,6 +702,170 @@ static void cm_reject_sidr_req(struct cm_id_private *cm_id_priv,
ib_send_cm_sidr_rep(&cm_id_priv->id, ¶m);
}
+static inline u8 cm_get_ip_ver(struct cm_hdr *hdr)
+{
+ return hdr->ip_version >> 4;
+}
+
+void cm_set_ip_ver(struct cm_hdr *hdr, u8 ip_ver)
+{
+ hdr->ip_version = (ip_ver << 4) | (hdr->ip_version & 0xF);
+}
+EXPORT_SYMBOL(cm_set_ip_ver);
+
+int cm_format_hdr(void *hdr, int family,
+ struct sockaddr *src_addr,
+ struct sockaddr *dst_addr)
+{
+ struct cm_hdr *cm_hdr;
+
+ cm_hdr = hdr;
+ cm_hdr->cm_version = RDMA_IP_CM_VERSION;
+ if (family == AF_INET) {
+ struct sockaddr_in *src4, *dst4;
+
+ src4 = (struct sockaddr_in *)src_addr;
+ dst4 = (struct sockaddr_in *)dst_addr;
+
+ cm_set_ip_ver(cm_hdr, 4);
+ cm_hdr->src_addr.ip4.addr = src4->sin_addr.s_addr;
+ cm_hdr->dst_addr.ip4.addr = dst4->sin_addr.s_addr;
+ cm_hdr->port = src4->sin_port;
+ } else if (family == AF_INET6) {
+ struct sockaddr_in6 *src6, *dst6;
+
+ src6 = (struct sockaddr_in6 *)src_addr;
+ dst6 = (struct sockaddr_in6 *)dst_addr;
+
+ cm_set_ip_ver(cm_hdr, 6);
+ cm_hdr->src_addr.ip6 = src6->sin6_addr;
+ cm_hdr->dst_addr.ip6 = dst6->sin6_addr;
+ cm_hdr->port = src6->sin6_port;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(cm_format_hdr);
+
+static void cm_save_ib_info(struct sockaddr *src_addr,
+ struct sockaddr *dst_addr,
+ struct ib_sa_path_rec *path)
+{
+ struct sockaddr_ib *ib;
+
+ if (src_addr) {
+ ib = (struct sockaddr_ib *)src_addr;
+ ib->sib_family = AF_IB;
+ ib->sib_pkey = path->pkey;
+ ib->sib_flowinfo = path->flow_label;
+ memcpy(&ib->sib_addr, &path->sgid, 16);
+ ib->sib_sid = path->service_id;
+ ib->sib_sid_mask = cpu_to_be64(0xffffffffffffffffULL);
+ ib->sib_scope_id = 0;
+ }
+ if (dst_addr) {
+ ib = (struct sockaddr_ib *)dst_addr;
+ ib->sib_family = AF_IB;
+ ib->sib_pkey = path->pkey;
+ ib->sib_flowinfo = path->flow_label;
+ memcpy(&ib->sib_addr, &path->dgid, 16);
+ }
+}
+
+static void cm_save_ip6_info(struct sockaddr *src_addr,
+ struct sockaddr *dst_addr,
+ struct cm_hdr *hdr,
+ __be16 local_port)
+{
+ struct sockaddr_in6 *ip6;
+
+ if (src_addr) {
+ ip6 = (struct sockaddr_in6 *)src_addr;
+ ip6->sin6_family = AF_INET6;
+ ip6->sin6_addr = hdr->dst_addr.ip6;
+ ip6->sin6_port = local_port;
+ }
+
+ if (dst_addr) {
+ ip6 = (struct sockaddr_in6 *)dst_addr;
+ ip6->sin6_family = AF_INET6;
+ ip6->sin6_addr = hdr->src_addr.ip6;
+ ip6->sin6_port = hdr->port;
+ }
+}
+
+static void cm_save_ip4_info(struct sockaddr *src_addr,
+ struct sockaddr *dst_addr,
+ struct cm_hdr *hdr,
+ __be16 local_port)
+{
+ struct sockaddr_in *ip4;
+
+ if (src_addr) {
+ ip4 = (struct sockaddr_in *)src_addr;
+ ip4->sin_family = AF_INET;
+ ip4->sin_addr.s_addr = hdr->dst_addr.ip4.addr;
+ ip4->sin_port = local_port;
+ }
+
+ if (dst_addr) {
+ ip4 = (struct sockaddr_in *)dst_addr;
+ ip4->sin_family = AF_INET;
+ ip4->sin_addr.s_addr = hdr->src_addr.ip4.addr;
+ ip4->sin_port = hdr->port;
+ }
+}
+
+static __be16 cm_port_from_service_id(__be64 service_id)
+{
+ return htons(be64_to_cpu(service_id));
+}
+
+static int cm_save_ip_info(struct sockaddr *src_addr,
+ struct sockaddr *dst_addr,
+ struct cm_work *work)
+{
+ struct cm_hdr *hdr;
+ __be16 port;
+
+ hdr = work->cm_event.private_data;
+ if (hdr->cm_version != RDMA_IP_CM_VERSION)
+ return -EINVAL;
+
+ port = cm_port_from_service_id(work->path->service_id);
+
+ switch (cm_get_ip_ver(hdr)) {
+ case 4:
+ cm_save_ip4_info(src_addr, dst_addr, hdr, port);
+ break;
+ case 6:
+ cm_save_ip6_info(src_addr, dst_addr, hdr, port);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+int cm_save_net_info(struct sockaddr *src_addr,
+ struct sockaddr *dst_addr,
+ struct ib_cm_event *ib_event)
+{
+ struct cm_work *work = container_of(ib_event, struct cm_work, cm_event);
+
+ if ((rdma_port_get_link_layer(work->port->cm_dev->ib_device,
+ work->port->port_num) ==
+ IB_LINK_LAYER_INFINIBAND) &&
+ (ib_event->event == IB_CM_REQ_RECEIVED)) {
+ cm_save_ib_info(src_addr, dst_addr,
+ ib_event->param.req_rcvd.primary_path);
+ return 0;
+ }
+
+ return cm_save_ip_info(src_addr, dst_addr, work);
+}
+EXPORT_SYMBOL(cm_save_net_info);
+
struct ib_cm_id *ib_create_cm_id(struct ib_device *device,
ib_cm_handler cm_handler,
void *context)
@@ -1260,6 +1425,7 @@ static void cm_format_paths_from_req(struct cm_req_msg *req_msg,
primary_path->packet_life_time =
cm_req_get_primary_local_ack_timeout(req_msg);
primary_path->packet_life_time -= (primary_path->packet_life_time > 0);
+ primary_path->service_id = req_msg->service_id;
if (req_msg->alt_local_lid) {
memset(alt_path, 0, sizeof *alt_path);
@@ -1281,6 +1447,7 @@ static void cm_format_paths_from_req(struct cm_req_msg *req_msg,
alt_path->packet_life_time =
cm_req_get_alt_local_ack_timeout(req_msg);
alt_path->packet_life_time -= (alt_path->packet_life_time > 0);
+ alt_path->service_id = req_msg->service_id;
}
}
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index aeb2417ec928..9f6faeb1de5f 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -179,23 +179,8 @@ struct iboe_mcast_work {
struct cma_multicast *mc;
};
-union cma_ip_addr {
- struct in6_addr ip6;
- struct {
- __be32 pad[3];
- __be32 addr;
- } ip4;
-};
-struct cma_hdr {
- u8 cma_version;
- u8 ip_version; /* IP version: 7:4 */
- __be16 port;
- union cma_ip_addr src_addr;
- union cma_ip_addr dst_addr;
-};
-#define CMA_VERSION 0x00
static int cma_comp(struct rdma_id_private *id_priv, enum rdma_cm_state comp)
{
@@ -234,16 +219,6 @@ static enum rdma_cm_state cma_exch(struct rdma_id_private *id_priv,
return old;
}
-static inline u8 cma_get_ip_ver(struct cma_hdr *hdr)
-{
- return hdr->ip_version >> 4;
-}
-
-static inline void cma_set_ip_ver(struct cma_hdr *hdr, u8 ip_ver)
-{
- hdr->ip_version = (ip_ver << 4) | (hdr->ip_version & 0xF);
-}
-
static void cma_attach_to_dev(struct rdma_id_private *id_priv,
struct cma_device *cma_dev)
{
@@ -839,93 +814,9 @@ static inline int cma_any_port(struct sockaddr *addr)
return !cma_port(addr);
}
-static void cma_save_ib_info(struct rdma_cm_id *id, struct rdma_cm_id *listen_id,
- struct ib_sa_path_rec *path)
-{
- struct sockaddr_ib *listen_ib, *ib;
-
- listen_ib = (struct sockaddr_ib *) &listen_id->route.addr.src_addr;
- ib = (struct sockaddr_ib *) &id->route.addr.src_addr;
- ib->sib_family = listen_ib->sib_family;
- ib->sib_pkey = path->pkey;
- ib->sib_flowinfo = path->flow_label;
- memcpy(&ib->sib_addr, &path->sgid, 16);
- ib->sib_sid = listen_ib->sib_sid;
- ib->sib_sid_mask = cpu_to_be64(0xffffffffffffffffULL);
- ib->sib_scope_id = listen_ib->sib_scope_id;
-
- ib = (struct sockaddr_ib *) &id->route.addr.dst_addr;
- ib->sib_family = listen_ib->sib_family;
- ib->sib_pkey = path->pkey;
- ib->sib_flowinfo = path->flow_label;
- memcpy(&ib->sib_addr, &path->dgid, 16);
-}
-
-static void cma_save_ip4_info(struct rdma_cm_id *id, struct rdma_cm_id *listen_id,
- struct cma_hdr *hdr)
-{
- struct sockaddr_in *listen4, *ip4;
-
- listen4 = (struct sockaddr_in *) &listen_id->route.addr.src_addr;
- ip4 = (struct sockaddr_in *) &id->route.addr.src_addr;
- ip4->sin_family = AF_INET;
- ip4->sin_addr.s_addr = hdr->dst_addr.ip4.addr;
- ip4->sin_port = listen4->sin_port;
-
- ip4 = (struct sockaddr_in *) &id->route.addr.dst_addr;
- ip4->sin_family = AF_INET;
- ip4->sin_addr.s_addr = hdr->src_addr.ip4.addr;
- ip4->sin_port = hdr->port;
-}
-
-static void cma_save_ip6_info(struct rdma_cm_id *id, struct rdma_cm_id *listen_id,
- struct cma_hdr *hdr)
-{
- struct sockaddr_in6 *listen6, *ip6;
-
- listen6 = (struct sockaddr_in6 *) &listen_id->route.addr.src_addr;
- ip6 = (struct sockaddr_in6 *) &id->route.addr.src_addr;
- ip6->sin6_family = AF_INET6;
- ip6->sin6_addr = hdr->dst_addr.ip6;
- ip6->sin6_port = listen6->sin6_port;
-
- ip6 = (struct sockaddr_in6 *) &id->route.addr.dst_addr;
- ip6->sin6_family = AF_INET6;
- ip6->sin6_addr = hdr->src_addr.ip6;
- ip6->sin6_port = hdr->port;
-}
-
-static int cma_save_net_info(struct rdma_cm_id *id, struct rdma_cm_id *listen_id,
- struct ib_cm_event *ib_event)
-{
- struct cma_hdr *hdr;
-
- if ((listen_id->route.addr.src_addr.ss_family == AF_IB) &&
- (ib_event->event == IB_CM_REQ_RECEIVED)) {
- cma_save_ib_info(id, listen_id, ib_event->param.req_rcvd.primary_path);
- return 0;
- }
-
- hdr = ib_event->private_data;
- if (hdr->cma_version != CMA_VERSION)
- return -EINVAL;
-
- switch (cma_get_ip_ver(hdr)) {
- case 4:
- cma_save_ip4_info(id, listen_id, hdr);
- break;
- case 6:
- cma_save_ip6_info(id, listen_id, hdr);
- break;
- default:
- return -EINVAL;
- }
- return 0;
-}
-
static inline int cma_user_data_offset(struct rdma_id_private *id_priv)
{
- return cma_family(id_priv) == AF_IB ? 0 : sizeof(struct cma_hdr);
+ return cma_family(id_priv) == AF_IB ? 0 : sizeof(struct cm_hdr);
}
static void cma_cancel_route(struct rdma_id_private *id_priv)
@@ -1195,7 +1086,9 @@ static struct rdma_id_private *cma_new_conn_id(struct rdma_cm_id *listen_id,
return NULL;
id_priv = container_of(id, struct rdma_id_private, id);
- if (cma_save_net_info(id, listen_id, ib_event))
+ if (cm_save_net_info((struct sockaddr *)&id->route.addr.src_addr,
+ (struct sockaddr *)&id->route.addr.dst_addr,
+ ib_event))
goto err;
rt = &id->route;
@@ -1241,7 +1134,9 @@ static struct rdma_id_private *cma_new_udp_id(struct rdma_cm_id *listen_id,
return NULL;
id_priv = container_of(id, struct rdma_id_private, id);
- if (cma_save_net_info(id, listen_id, ib_event))
+ if (cm_save_net_info((struct sockaddr *)&id->route.addr.src_addr,
+ (struct sockaddr *)&id->route.addr.dst_addr,
+ ib_event))
goto err;
if (!cma_any_addr((struct sockaddr *) &id->route.addr.src_addr)) {
@@ -1369,7 +1264,7 @@ EXPORT_SYMBOL(rdma_get_service_id);
static void cma_set_compare_data(enum rdma_port_space ps, struct sockaddr *addr,
struct ib_cm_compare_data *compare)
{
- struct cma_hdr *cma_data, *cma_mask;
+ struct cm_hdr *cma_data, *cma_mask;
__be32 ip4_addr;
struct in6_addr ip6_addr;
@@ -1380,8 +1275,8 @@ static void cma_set_compare_data(enum rdma_port_space ps, struct sockaddr *addr,
switch (addr->sa_family) {
case AF_INET:
ip4_addr = ((struct sockaddr_in *) addr)->sin_addr.s_addr;
- cma_set_ip_ver(cma_data, 4);
- cma_set_ip_ver(cma_mask, 0xF);
+ cm_set_ip_ver(cma_data, 4);
+ cm_set_ip_ver(cma_mask, 0xF);
if (!cma_any_addr(addr)) {
cma_data->dst_addr.ip4.addr = ip4_addr;
cma_mask->dst_addr.ip4.addr = htonl(~0);
@@ -1389,8 +1284,8 @@ static void cma_set_compare_data(enum rdma_port_space ps, struct sockaddr *addr,
break;
case AF_INET6:
ip6_addr = ((struct sockaddr_in6 *) addr)->sin6_addr;
- cma_set_ip_ver(cma_data, 6);
- cma_set_ip_ver(cma_mask, 0xF);
+ cm_set_ip_ver(cma_data, 6);
+ cm_set_ip_ver(cma_mask, 0xF);
if (!cma_any_addr(addr)) {
cma_data->dst_addr.ip6 = ip6_addr;
memset(&cma_mask->dst_addr.ip6, 0xFF,
@@ -2615,35 +2510,6 @@ err1:
}
EXPORT_SYMBOL(rdma_bind_addr);
-static int cma_format_hdr(void *hdr, struct rdma_id_private *id_priv)
-{
- struct cma_hdr *cma_hdr;
-
- cma_hdr = hdr;
- cma_hdr->cma_version = CMA_VERSION;
- if (cma_family(id_priv) == AF_INET) {
- struct sockaddr_in *src4, *dst4;
-
- src4 = (struct sockaddr_in *) cma_src_addr(id_priv);
- dst4 = (struct sockaddr_in *) cma_dst_addr(id_priv);
-
- cma_set_ip_ver(cma_hdr, 4);
- cma_hdr->src_addr.ip4.addr = src4->sin_addr.s_addr;
- cma_hdr->dst_addr.ip4.addr = dst4->sin_addr.s_addr;
- cma_hdr->port = src4->sin_port;
- } else if (cma_family(id_priv) == AF_INET6) {
- struct sockaddr_in6 *src6, *dst6;
-
- src6 = (struct sockaddr_in6 *) cma_src_addr(id_priv);
- dst6 = (struct sockaddr_in6 *) cma_dst_addr(id_priv);
-
- cma_set_ip_ver(cma_hdr, 6);
- cma_hdr->src_addr.ip6 = src6->sin6_addr;
- cma_hdr->dst_addr.ip6 = dst6->sin6_addr;
- cma_hdr->port = src6->sin6_port;
- }
- return 0;
-}
static int cma_sidr_rep_handler(struct ib_cm_id *cm_id,
struct ib_cm_event *ib_event)
@@ -2731,7 +2597,9 @@ static int cma_resolve_ib_udp(struct rdma_id_private *id_priv,
conn_param->private_data_len);
if (private_data) {
- ret = cma_format_hdr(private_data, id_priv);
+ ret = cm_format_hdr(private_data, cma_family(id_priv),
+ cma_src_addr(id_priv),
+ cma_dst_addr(id_priv));
if (ret)
goto out;
req.private_data = private_data;
@@ -2796,7 +2664,9 @@ static int cma_connect_ib(struct rdma_id_private *id_priv,
route = &id_priv->id.route;
if (private_data) {
- ret = cma_format_hdr(private_data, id_priv);
+ ret = cm_format_hdr(private_data, cma_family(id_priv),
+ cma_src_addr(id_priv),
+ cma_dst_addr(id_priv));
if (ret)
goto out;
req.private_data = private_data;
diff --git a/include/rdma/ib_cm.h b/include/rdma/ib_cm.h
index 0e3ff30647d5..e418a11afcfe 100644
--- a/include/rdma/ib_cm.h
+++ b/include/rdma/ib_cm.h
@@ -274,6 +274,52 @@ struct ib_cm_event {
#define CM_LAP_ATTR_ID cpu_to_be16(0x0019)
#define CM_APR_ATTR_ID cpu_to_be16(0x001A)
+union cm_ip_addr {
+ struct in6_addr ip6;
+ struct {
+ __be32 pad[3];
+ __be32 addr;
+ } ip4;
+};
+
+struct cm_hdr {
+ u8 cm_version;
+ u8 ip_version; /* IP version: 7:4 */
+ __be16 port;
+ union cm_ip_addr src_addr;
+ union cm_ip_addr dst_addr;
+};
+
+#define RDMA_IP_CM_VERSION 0x00
+
+/**
+ * cm_format_hdr - Fill in a cm_hdr struct according to connection details
+ * @hdr: cm_hdr struct to fill
+ * @family: ip family of the addresses - AF_INET or AF_INTET6
+ * @src_addr: source address of the connection
+ * @dst_addr: destination address of the connection
+ **/
+int cm_format_hdr(void *hdr, int family,
+ struct sockaddr *src_addr,
+ struct sockaddr *dst_addr);
+
+/**
+ * cm_save_net_info - saves ib connection event details
+ * @src_addr: source address of the connection
+ * @dst_addr: destination address of the connection
+ * @ib_event: ib event to take connection details from
+ **/
+int cm_save_net_info(struct sockaddr *src_addr,
+ struct sockaddr *dst_addr,
+ struct ib_cm_event *ib_event);
+
+/**
+ * cm_set_ip_ver - sets the ip version of a cm_hdr struct
+ * @hdr: cm_hdr struct to change
+ * @ip_ver: ip version to set - a 4 bit value
+ **/
+void cm_set_ip_ver(struct cm_hdr *hdr, u8 ip_ver);
+
/**
* ib_cm_handler - User-defined callback to process communication events.
* @cm_id: Communication identifier associated with the reported event.
--
1.7.11.2
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox