Netdev List
 help / color / mirror / Atom feed
* Re: ath9k: fix spelling mistake: "meaurement" -> "measurement"
From: Kalle Valo @ 2017-01-12 11:01 UTC (permalink / raw)
  To: Colin Ian King
  Cc: QCA ath9k Development, Kalle Valo, linux-wireless, ath9k-devel,
	netdev, linux-kernel
In-Reply-To: <20161230140647.12945-1-colin.king@canonical.com>

Colin Ian King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
> 
> Trivial fix to spelling mistake in ath_err message
> 
> Signed-off-by: Colin Ian King <colin.king@canonical.com>

Patch applied to ath-next branch of ath.git, thanks.

714ee339ff90 ath9k: fix spelling mistake: "meaurement" -> "measurement"

-- 
https://patchwork.kernel.org/patch/9492191/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

^ permalink raw reply

* Re: [PATCH v2 2/2] stmmac: rename it to synopsys
From: Joao Pinto @ 2017-01-12 11:09 UTC (permalink / raw)
  To: Alexandre Torgue, Joao Pinto, Florian Fainelli, davem
  Cc: lars.persson, niklass, peppe.cavallaro, netdev
In-Reply-To: <57d96ccb-7fd4-0707-4902-a5bdd2a6ef39@st.com>

Hi Alex, good morning!

Às 10:11 AM de 1/12/2017, Alexandre Torgue escreveu:
>>
>> Lets not name it synopsys, for me it is totally fine, but naming it
>> stmicro/stmmac is not the right way because it seems like it is a driver just
>> for stmicro products, which is not, is for products that use Designware Ethernet
>> IPs.
>>
>> I am volunteering to do this work, let's discuss this.
> 
> For me it makes no sens to rename only folder (stmicro/stmmac by synopsys) and
> keep stmmac* inside a synopsys folder (that is very confusing). If you propose
> that you have to change all.
> 
> BUT doing that, we will lose all stmmac driver story and we don't want that.

Totally understand your point. Do you agree on this approach?
rename "stmicro" to "dwc" (designware controllers) and leave stmmac as it is
today. This small change is enough in my point of view and sole the problems you
refer. We would have net/ethernet/dwc/stmmac/.

I can also rename the dwmac4 files and functions to eqos, since soon we will
have a new eqos version.

dwmac4.h -> eqos.h
dwmac4_core.c -> eqos_core.c
dwmac4_descs.c -> eqos_descs.c
dwmac4_descs.h -> eqos_descs.h
dwmac4_dma.c -> eqos_dma.c
dwmac4_dma.h -> eqos_dma.h
dwmac4_lib.c -> eqos_lib.c

What do you think about this approach?

Thanks,
Joao

> 
> 
> 
>>
>> Thanks,
>> Joao
>>
>>

^ permalink raw reply

* Re: [PATCH net-next 2/2] bpf: allow b/h/w/dw access for bpf's cb in ctx
From: Daniel Borkmann @ 2017-01-12 10:53 UTC (permalink / raw)
  To: Quentin Monnet, davem; +Cc: alexei.starovoitov, netdev
In-Reply-To: <bb078a63-6bcc-22f8-c98e-8445f66678c9@6wind.com>

On 01/12/2017 09:25 AM, Quentin Monnet wrote:
> 2017-01-12 (02:21 +0100) ~ Daniel Borkmann <daniel@iogearbox.net>
[...]
>> diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_verifier.c
>> index 9bb4534..f664bed 100644
>> --- a/tools/testing/selftests/bpf/test_verifier.c
>> +++ b/tools/testing/selftests/bpf/test_verifier.c
>> @@ -859,15 +859,451 @@ struct test_val {
>
> [...]
>
>> +	{
>> +		"check cb access: doulbe, oob 5",
>> +		.insns = {
>> +			BPF_MOV64_IMM(BPF_REG_0, 0),
>> +			BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_1,
>> +				    offsetof(struct __sk_buff, cb[4]) + 8),
>> +			BPF_EXIT_INSN(),
>> +		},
>> +		.errstr = "invalid bpf_context access",
>> +		.result = REJECT,
>> +	},
>
> Nitpicking: typo ("doulbe").

Thanks for spotting, I've sent out a v2.

^ permalink raw reply

* Re: [PATCH net-next] secure_seq: fix sparse errors
From: Jason A. Donenfeld @ 2017-01-12 11:42 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1484187037.15816.21.camel@edumazet-glaptop3.roam.corp.google.com>

Nice catch, thanks.

Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>

^ permalink raw reply

* Re: [PATCH 9/9] treewide: Inline ib_dma_map_*() functions
From: Sagi Grimberg @ 2017-01-12 11:45 UTC (permalink / raw)
  To: Bart Van Assche, Doug Ledford
  Cc: Latchesar Ionkov, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
	linux-nfs-u79uwXL29TY76Z2rM5mHXA, Andreas Dilger,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
	Trond Myklebust, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Anna Schumaker,
	Oleg Drokin, Eric Van Hensbergen,
	target-devel-u79uwXL29TY76Z2rM5mHXA, Ron Minnich, James Simmons,
	v9fs-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
	rds-devel-N0ozoZBvEnrZJqsBc5GL+g, David S . Miller,
	lustre-devel-aLEFhgZF4x6X6Mz3xDxJMA
In-Reply-To: <20170111005648.14988-10-bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>

Reviewed-by: Sagi Grimberg <sagi-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
--
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

* Re: [PATCH/RFC net] ravb: Remove Rx overflow log messages
From: Sergei Shtylyov @ 2017-01-12 11:52 UTC (permalink / raw)
  To: Simon Horman, David Miller; +Cc: Magnus Damm, netdev, linux-renesas-soc
In-Reply-To: <1484210470-3095-1-git-send-email-horms+renesas@verge.net.au>

On 01/12/2017 11:41 AM, Simon Horman wrote:

> From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
>
> Remove Rx overflow log messages as in an environment where logging results
> in network traffic logging may cause further overflows.
>
> Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
> Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
> [simon: reworked changelog]
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>

Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

MBR, Sergei

^ permalink raw reply

* Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings
From: Sergei Shtylyov @ 2017-01-12 12:03 UTC (permalink / raw)
  To: Simon Horman; +Cc: David Miller, Magnus Damm, netdev, linux-renesas-soc
In-Reply-To: <20170112091116.GC7724@verge.net.au>

On 01/12/2017 12:11 PM, Simon Horman wrote:

>>> From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
>>>
>>> "swiotlb buffer is full" errors occur after repeated initialisation of a
>>> device - f.e. suspend/resume or ip link set up/down. This is because memory
>>> mapped using dma_map_single() in ravb_ring_format() and ravb_start_xmit()
>>> is not released.  Resolve this problem by unmapping descriptors when
>>> freeing rings.
>>>
>>> Note, ravb_tx_free() is moved but not otherwise modified by this patch.
>>>
>>> Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
>>> [simon: reworked]
>>> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>>> --
>>> v1 [Kazuya Mizuguchi]
>>>
>>> v2 [Simon Horman]
>>> * As suggested by Sergei Shtylyov
>>>  - Use dma_mapping_error() and rx_desc->ds_cc when unmapping RX descriptors;
>>>    this is consistent with the way that they are mapped
>>>  - Use ravb_tx_free() to clear TX descriptors
>>
>>    Not sure that was good idea (sorry)... ravb_tx_ring() only unmaps the
>> transmitted buffers, while we need to unmap everything...
>>
>>> * Reduce scope of new local variable
>>> ---
>>> drivers/net/ethernet/renesas/ravb_main.c | 89 ++++++++++++++++++--------------
>>> 1 file changed, 51 insertions(+), 38 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
>>> index 92d7692c840d..1797c48e3176 100644
>>> --- a/drivers/net/ethernet/renesas/ravb_main.c
>>> +++ b/drivers/net/ethernet/renesas/ravb_main.c
>>> @@ -179,6 +179,44 @@ static struct mdiobb_ops bb_ops = {
>>> 	.get_mdio_data = ravb_get_mdio_data,
>>> };
>>>
>>> +/* Free TX skb function for AVB-IP */
>>> +static int ravb_tx_free(struct net_device *ndev, int q)
>>> +{
>>> +	struct ravb_private *priv = netdev_priv(ndev);
>>> +	struct net_device_stats *stats = &priv->stats[q];
>>> +	struct ravb_tx_desc *desc;
>>> +	int free_num = 0;
>>> +	int entry;
>>> +	u32 size;
>>> +
>>> +	for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; priv->dirty_tx[q]++) {
>>> +		entry = priv->dirty_tx[q] % (priv->num_tx_ring[q] *
>>> +					     NUM_TX_DESC);
>>> +		desc = &priv->tx_ring[q][entry];
>>> +		if (desc->die_dt != DT_FEMPTY)
>>
>>    Here, it stop once an untransmitted buffer is encountered...
>
> Yes, I see that now.
>
> I wonder if we should:
>
> a) paramatise ravb_tx_free() so it may either clear all transmitted buffers
>    (current behaviour) or all buffers (new behaviour).
> b) provide a different version of this loop in ravb_ring_free()
>
> What are your thoughts?

    I'm voting for (b).

[...]

MBR, Sergei

^ permalink raw reply

* [PATCH net] ravb: Remove Rx overflow log messages
From: Simon Horman @ 2017-01-12 12:21 UTC (permalink / raw)
  To: David Miller, Sergei Shtylyov; +Cc: Magnus Damm, netdev, linux-renesas-soc

From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>

Remove Rx overflow log messages as in an environment where logging results
in network traffic logging may cause further overflows.

Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
[simon: reworked changelog]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes since RFC:
* Added Ack from Sergei
---
 drivers/net/ethernet/renesas/ravb_main.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 92d7692c840d..5e5ad978eab9 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -926,14 +926,10 @@ static int ravb_poll(struct napi_struct *napi, int budget)
 	/* Receive error message handling */
 	priv->rx_over_errors =  priv->stats[RAVB_BE].rx_over_errors;
 	priv->rx_over_errors += priv->stats[RAVB_NC].rx_over_errors;
-	if (priv->rx_over_errors != ndev->stats.rx_over_errors) {
+	if (priv->rx_over_errors != ndev->stats.rx_over_errors)
 		ndev->stats.rx_over_errors = priv->rx_over_errors;
-		netif_err(priv, rx_err, ndev, "Receive Descriptor Empty\n");
-	}
-	if (priv->rx_fifo_errors != ndev->stats.rx_fifo_errors) {
+	if (priv->rx_fifo_errors != ndev->stats.rx_fifo_errors)
 		ndev->stats.rx_fifo_errors = priv->rx_fifo_errors;
-		netif_err(priv, rx_err, ndev, "Receive FIFO Overflow\n");
-	}
 out:
 	return budget - quota;
 }
-- 
2.7.0.rc3.207.g0ac5344

^ permalink raw reply related

* Re: [PATCHv3 2/6] sh_eth: add generic wake-on-lan support via magic packet
From: Sergei Shtylyov @ 2017-01-12 12:55 UTC (permalink / raw)
  To: Niklas Söderlund, Simon Horman, netdev, linux-renesas-soc
  Cc: Geert Uytterhoeven, linux-pm
In-Reply-To: <20170109153409.13956-3-niklas.soderlund+renesas@ragnatech.se>

Hello!

On 01/09/2017 06:34 PM, Niklas Söderlund wrote:

> Add generic functionality to support Wake-on-LAN using MagicPacket which
> are supported by at least a few versions of sh_eth. Only add
> functionality for WoL, no specific sh_eth versions are marked to support
> WoL yet.
>
> WoL is enabled in the suspend callback by setting MagicPacket detection
> and disabling all interrupts expect MagicPacket. In the resume path the
> driver needs to reset the hardware to rearm the WoL logic, this prevents
> the driver from simply restoring the registers and to take advantage of
> that sh_eth was not suspended to reduce resume time. To reset the
> hardware the driver closes and reopens the device just like it would do
> in a normal suspend/resume scenario without WoL enabled, but it both
> closes and opens the device in the resume callback since the device
> needs to be open for WoL to work.
>
> One quirk needed for WoL is that the module clock needs to be prevented
> from being switched off by Runtime PM. To keep the clock alive the
> suspend callback need to call clk_enable() directly to increase the
> usage count of the clock. Then when Runtime PM decreases the clock usage
> count it won't reach 0 and be switched off.
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> ---
>  drivers/net/ethernet/renesas/sh_eth.c | 114 +++++++++++++++++++++++++++++++---
>  drivers/net/ethernet/renesas/sh_eth.h |   3 +
>  2 files changed, 109 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
> index 8a784dce45fa..542c92b57b35 100644
> --- a/drivers/net/ethernet/renesas/sh_eth.c
> +++ b/drivers/net/ethernet/renesas/sh_eth.c
> @@ -1552,6 +1552,8 @@ static void sh_eth_emac_interrupt(struct net_device *ndev)
>  			sh_eth_rcv_snd_enable(ndev);
>  		}
>  	}
> +	if (felic_stat & ECSR_MPD)
> +		pm_wakeup_event(&mdp->pdev->dev, 0);

    Hum, seeing a corner case: if we're ignoring the link interrupt (and it 
does occur along with ECSR.MPD, we'll return and miss this check. It would 
have been preferable to add this code above the ECSR.LCHNG handler...

[...]
> @@ -3150,15 +3189,67 @@ static int sh_eth_drv_remove(struct platform_device *pdev)
>
>  #ifdef CONFIG_PM
>  #ifdef CONFIG_PM_SLEEP
> +static int sh_eth_wol_setup(struct net_device *ndev)
> +{
> +	struct sh_eth_private *mdp = netdev_priv(ndev);
> +
> +	/* Only allow ECI interrupts */
> +	synchronize_irq(ndev->irq);
> +	napi_disable(&mdp->napi);
> +	sh_eth_write(ndev, DMAC_M_ECI, EESIPR);
> +
> +	/* Enable MagicPacket */
> +	sh_eth_modify(ndev, ECMR, 0, ECMR_MPDE);

    I'd prefer sh_eth_modify(ndev, ECMR, ECMR_MPDE, ECMR_MPDE) to be 
consistent with my other code...

[...]

MBR, Sergei


^ permalink raw reply

* To netlink or not to netlink, that is the question
From: Jason A. Donenfeld @ 2017-01-12 13:01 UTC (permalink / raw)
  To: Netdev

Hey folks,

A few months ago I switched away from using netlink in wireguard,
preferring instead to use ioctl. I had come up against limitations in
rtnetlink, and ioctl presented a straightforward hard to screw-up
alternative. The very simple API is documented here:
https://git.zx2c4.com/WireGuard/tree/src/uapi.h

This works well, and I'm reluctant to change it, but as I do more
complicated things, and as kernel submission time looms nearer, I'm
kept up at night by the notion that maybe I ought to give netlink
another chance. But how?

For each wireguard interface, there are three types of structures for
userspace to configure. There is one wgdevice for each interface. Each
wgdevice has a variable amount (up to 2^16) of wgpeers. Each wgpeer
has a variable amount (up to 2^16) of wgipmasks. I'd like an interface
to get and set all of these at once, atomically.

Presently, with the ioctl, I just have a simple get ioctl and a simple
set ioctl. The set one passes a user space pointer, which is read
incrementally in kernel space. The get one will first return how much
userspace should allocate, and then when called again will write
incrementally into a provided userspace buffer up to a passed-in
maximum number of bytes. Very basic, I'm quite happy.

When I had tried to do this priorly with netlink, I did it by defining
changelink and fill_info in rtnl_link_ops. For changelink, I iterated
through the netlink objects, and for fill_info, I filled in the skb
with netlink objects. This was a bit more complex but basically
worked. Except netlink skbs have a maximum size and are buffered,
which means things broke entirely when trying to read or write logs of
wgpeers or lots of wgipmasks. So, the meager interfaces afforded to me
by rtnl_link_ops are insufficient. Doing anything beyond this, either
by registering new rtnetlink messages, or by using generic netlink,
seemed overwhelmingly complex and undesirable.

So I'm wondering -- is there a good way to be doing this with netlink?
Or am I right to stay with ioctl?

Thanks,
Jason

^ permalink raw reply

* Re: [PATCH] can: Fix kernel panic at security_sock_rcv_skb
From: Eric Dumazet @ 2017-01-12 13:01 UTC (permalink / raw)
  To: Oliver Hartkopp
  Cc: Liu ShuoX, linux-kernel, yanmin_zhang, shuox.liu, Zhang Yanmin,
	He, Bo, Marc Kleine-Budde, David S. Miller,
	open list:CAN NETWORK LAYER, open list:NETWORKING [GENERAL]
In-Reply-To: <0e458012-e97b-298d-296e-ed25e35689a0@hartkopp.net>

On Thu, 2017-01-12 at 09:22 +0100, Oliver Hartkopp wrote:
> 
> On 01/12/2017 07:33 AM, Liu ShuoX wrote:
> > From: Zhang Yanmin <yanmin.zhang@intel.com>
> >
> > The patch is for fix the below kernel panic:
> > BUG: unable to handle kernel NULL pointer dereference at (null)
> > IP: [<ffffffff81495e25>] selinux_socket_sock_rcv_skb+0x65/0x2a0
> >
> > Call Trace:
> >  <IRQ>
> >  [<ffffffff81485d8c>] security_sock_rcv_skb+0x4c/0x60
> >  [<ffffffff81d55771>] sk_filter+0x41/0x210
> >  [<ffffffff81d12913>] sock_queue_rcv_skb+0x53/0x3a0
> >  [<ffffffff81f0a2b3>] raw_rcv+0x2a3/0x3c0
> >  [<ffffffff81f06eab>] can_rcv_filter+0x12b/0x370
> >  [<ffffffff81f07af9>] can_receive+0xd9/0x120
> >  [<ffffffff81f07beb>] can_rcv+0xab/0x100
> >  [<ffffffff81d362ac>] __netif_receive_skb_core+0xd8c/0x11f0
> >  [<ffffffff81d36734>] __netif_receive_skb+0x24/0xb0
> >  [<ffffffff81d37f67>] process_backlog+0x127/0x280
> >  [<ffffffff81d36f7b>] net_rx_action+0x33b/0x4f0
> >  [<ffffffff810c88d4>] __do_softirq+0x184/0x440
> >  [<ffffffff81f9e86c>] do_softirq_own_stack+0x1c/0x30
> >  <EOI>
> >  [<ffffffff810c76fb>] do_softirq.part.18+0x3b/0x40
> >  [<ffffffff810c8bed>] do_softirq+0x1d/0x20
> >  [<ffffffff81d30085>] netif_rx_ni+0xe5/0x110
> >  [<ffffffff8199cc87>] slcan_receive_buf+0x507/0x520
> >  [<ffffffff8167ef7c>] flush_to_ldisc+0x21c/0x230
> >  [<ffffffff810e3baf>] process_one_work+0x24f/0x670
> >  [<ffffffff810e44ed>] worker_thread+0x9d/0x6f0
> >  [<ffffffff810e4450>] ? rescuer_thread+0x480/0x480
> >  [<ffffffff810ebafc>] kthread+0x12c/0x150
> >  [<ffffffff81f9ccef>] ret_from_fork+0x3f/0x70
> >
> > The sk dereferenced in panic has been released. After the rcu_call in
> > can_rx_unregister, receiver was protected by RCU but inner data was
> > not, then later sk will be freed while other CPU is still using it.
> > We need wait here to make sure sk referenced via receiver was safe.
> >
> > => security_sk_free
> > => sk_destruct
> > => __sk_free
> > => sk_free
> > => raw_release
> > => sock_release
> > => sock_close
> > => __fput
> > => ____fput
> > => task_work_run
> > => exit_to_usermode_loop
> > => syscall_return_slowpath
> > => int_ret_from_sys_call
> >
> > Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com>
> > Signed-off-by: He, Bo <bo.he@intel.com>
> > Signed-off-by: Liu Shuo A <shuo.a.liu@intel.com>
> > ---
> >  net/can/af_can.c | 14 ++++++++------
> >  net/can/af_can.h |  1 -
> >  2 files changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/net/can/af_can.c b/net/can/af_can.c
> > index 1108079..fcbe971 100644
> > --- a/net/can/af_can.c
> > +++ b/net/can/af_can.c
> > @@ -517,10 +517,8 @@ int can_rx_register(struct net_device *dev, canid_t can_id, canid_t mask,
> >  /*
> >   * can_rx_delete_receiver - rcu callback for single receiver entry removal
> >   */
> > -static void can_rx_delete_receiver(struct rcu_head *rp)
> > +static void can_rx_delete_receiver(struct receiver *r)
> >  {
> > -	struct receiver *r = container_of(rp, struct receiver, rcu);
> > -
> >  	kmem_cache_free(rcv_cache, r);
> >  }
> >
> > @@ -595,9 +593,13 @@ void can_rx_unregister(struct net_device *dev, canid_t can_id, canid_t mask,
> >   out:
> >  	spin_unlock(&can_rcvlists_lock);
> >
> > -	/* schedule the receiver item for deletion */
> > -	if (r)
> > -		call_rcu(&r->rcu, can_rx_delete_receiver);
> > +	/* synchronize_rcu to wait until a grace period has elapsed, to make
> > +	 * sure all receiver's sk dereferenced by others.
> > +	 */
> > +	if (r) {
> > +		synchronize_rcu();
> > +		can_rx_delete_receiver(r);
> 
> Nitpick: When can_rx_delete_receiver() just contains 
> kmem_cache_free(rcv_cache, r), then the function definition should be 
> removed.
> 
> But my main concern is:
> 
> The reason why can_rx_delete_receiver() was introduced was the need to 
> remove a huge number of receivers with can_rx_unregister().
> 
> When you call synchronize_rcu() after each receiver removal this would 
> potentially lead to a big performance issue when e.g. closing CAN_RAW 
> sockets with a high number of receivers.
> 
> So the idea was to remove/unlink the receiver hlist_del_rcu(&r->list) 
> and also kmem_cache_free(rcv_cache, r) by some rcu mechanism - so that 
> all elements are cleaned up by rcu at a later point.
> 
> Is it possible that the problems emerge due to hlist_del_rcu(&r->list) 
> and you accidently fix it with your introduced synchronize_rcu()?

I agree this patch does not fix the root cause.

The main problem seems that the sockets themselves are not RCU
protected.

If CAN uses RCU for delivery, then sockets should be freed only after
one RCU grace period.

On recent kernels, following patch could help :

diff --git a/net/can/af_can.c b/net/can/af_can.c
index 1108079d934f8383a599d7997b08100fca0465e9..353beaefee7ea3631eb429b011604906b964465e 100644
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -189,6 +189,7 @@ static int can_create(struct net *net, struct socket *sock, int protocol,
 
 	sock_init_data(sock, sk);
 	sk->sk_destruct = can_sock_destruct;
+	sock_set_flag(sk, SOCK_RCU_FREE);
 
 	if (sk->sk_prot->init)
 		err = sk->sk_prot->init(sk);


For older kernels, the following could be used :

 net/can/af_can.c |   13 ++++++++++---
 net/can/af_can.h |    3 ++-
 net/can/bcm.c    |    4 ++--
 net/can/gw.c     |    2 +-
 net/can/raw.c    |    4 ++--
 5 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/net/can/af_can.c b/net/can/af_can.c
index 1108079d934f8383a599d7997b08100fca0465e9..48352caa5430610b9811c86e06adefa084561ef9 100644
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -468,7 +468,7 @@ static struct hlist_head *find_rcv_list(canid_t *can_id, canid_t *mask,
  */
 int can_rx_register(struct net_device *dev, canid_t can_id, canid_t mask,
 		    void (*func)(struct sk_buff *, void *), void *data,
-		    char *ident)
+		    char *ident, struct sock *sk)
 {
 	struct receiver *r;
 	struct hlist_head *rl;
@@ -496,6 +496,7 @@ int can_rx_register(struct net_device *dev, canid_t can_id, canid_t mask,
 		r->func    = func;
 		r->data    = data;
 		r->ident   = ident;
+		r->sk      = sk;
 
 		hlist_add_head_rcu(&r->list, rl);
 		d->entries++;
@@ -520,8 +521,11 @@ EXPORT_SYMBOL(can_rx_register);
 static void can_rx_delete_receiver(struct rcu_head *rp)
 {
 	struct receiver *r = container_of(rp, struct receiver, rcu);
-
+	struct sock *sk = r->sk;
+	
 	kmem_cache_free(rcv_cache, r);
+	if (sk)
+		sock_put(sk);
 }
 
 /**
@@ -596,8 +600,11 @@ void can_rx_unregister(struct net_device *dev, canid_t can_id, canid_t mask,
 	spin_unlock(&can_rcvlists_lock);
 
 	/* schedule the receiver item for deletion */
-	if (r)
+	if (r) {
+		if (r->sk)
+			sock_hold(r->sk);
 		call_rcu(&r->rcu, can_rx_delete_receiver);
+	}
 }
 EXPORT_SYMBOL(can_rx_unregister);
 
diff --git a/net/can/af_can.h b/net/can/af_can.h
index fca0fe9fc45a497cdf3da82d5414e846e7cc61b7..b86f5129e8385fe84ef671bb914e8e05c2977ca0 100644
--- a/net/can/af_can.h
+++ b/net/can/af_can.h
@@ -50,13 +50,14 @@
 
 struct receiver {
 	struct hlist_node list;
-	struct rcu_head rcu;
 	canid_t can_id;
 	canid_t mask;
 	unsigned long matches;
 	void (*func)(struct sk_buff *, void *);
 	void *data;
 	char *ident;
+	struct sock *sk;
+	struct rcu_head rcu;
 };
 
 #define CAN_SFF_RCV_ARRAY_SZ (1 << CAN_SFF_ID_BITS)
diff --git a/net/can/bcm.c b/net/can/bcm.c
index 21ac75390e3d64f795faad074b515d34ce0bbfa3..5c94071819188a2b92db9ae7fe1e0d41fb9a27c6 100644
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -1216,7 +1216,7 @@ static int bcm_rx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,
 				err = can_rx_register(dev, op->can_id,
 						      REGMASK(op->can_id),
 						      bcm_rx_handler, op,
-						      "bcm");
+						      "bcm", sk);
 
 				op->rx_reg_dev = dev;
 				dev_put(dev);
@@ -1225,7 +1225,7 @@ static int bcm_rx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,
 		} else
 			err = can_rx_register(NULL, op->can_id,
 					      REGMASK(op->can_id),
-					      bcm_rx_handler, op, "bcm");
+					      bcm_rx_handler, op, "bcm", sk);
 		if (err) {
 			/* this bcm rx op is broken -> remove it */
 			list_del(&op->list);
diff --git a/net/can/gw.c b/net/can/gw.c
index a54ab0c821048ab2034bf32cef3c1f35e0dc82a5..7056a1a2bb70098e691ce557f05e5bc1f27cb42f 100644
--- a/net/can/gw.c
+++ b/net/can/gw.c
@@ -442,7 +442,7 @@ static inline int cgw_register_filter(struct cgw_job *gwj)
 {
 	return can_rx_register(gwj->src.dev, gwj->ccgw.filter.can_id,
 			       gwj->ccgw.filter.can_mask, can_can_gw_rcv,
-			       gwj, "gw");
+			       gwj, "gw", NULL);
 }
 
 static inline void cgw_unregister_filter(struct cgw_job *gwj)
diff --git a/net/can/raw.c b/net/can/raw.c
index b075f028d7e23958e9433a4b19f4475ad930b547..6dc546a06673ff41fc121c546ebd0567bb0da05f 100644
--- a/net/can/raw.c
+++ b/net/can/raw.c
@@ -190,7 +190,7 @@ static int raw_enable_filters(struct net_device *dev, struct sock *sk,
 	for (i = 0; i < count; i++) {
 		err = can_rx_register(dev, filter[i].can_id,
 				      filter[i].can_mask,
-				      raw_rcv, sk, "raw");
+				      raw_rcv, sk, "raw", sk);
 		if (err) {
 			/* clean up successfully registered filters */
 			while (--i >= 0)
@@ -211,7 +211,7 @@ static int raw_enable_errfilter(struct net_device *dev, struct sock *sk,
 
 	if (err_mask)
 		err = can_rx_register(dev, 0, err_mask | CAN_ERR_FLAG,
-				      raw_rcv, sk, "raw");
+				      raw_rcv, sk, "raw", sk);
 
 	return err;
 }

^ permalink raw reply related

* Re: [PATCH 9/9] treewide: Inline ib_dma_map_*() functions
From: Leon Romanovsky @ 2017-01-12 13:09 UTC (permalink / raw)
  To: Bart Van Assche
  Cc: Latchesar Ionkov, devel, linux-nfs, Andreas Dilger,
	David S . Miller, linux-rdma, netdev, Trond Myklebust,
	linux-kernel, linux-nvme, rds-devel, Oleg Drokin,
	Eric Van Hensbergen, Doug Ledford, target-devel, v9fs-developer,
	Ron Minnich, Anna Schumaker, lustre-devel
In-Reply-To: <20170111005648.14988-10-bart.vanassche@sandisk.com>


[-- Attachment #1.1: Type: text/plain, Size: 2051 bytes --]

On Tue, Jan 10, 2017 at 04:56:48PM -0800, Bart Van Assche wrote:
> Almost all changes in this patch except the removal of local variables
> that became superfluous and the actual removal of the ib_dma_map_*()
> functions have been generated as follows:
>
> git grep -lE 'ib_(sg_|)dma_' |
>   xargs -d\\n \
>     sed -i -e 's/\([^[:alnum:]_]\)ib_dma_\([^(]*\)(\&\([^,]\+\),/\1dma_\2(\3.dma_device,/g' \
>            -e 's/\([^[:alnum:]_]\)ib_dma_\([^(]*\)(\([^,]\+\),/\1dma_\2(\3->dma_device,/g' \
> 	   -e 's/ib_sg_dma_\(len\|address\)(\([^,]\+\), /sg_dma_\1(/g'
>
> Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> Cc: Andreas Dilger <andreas.dilger@intel.com>
> Cc: Anna Schumaker <anna.schumaker@netapp.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Eric Van Hensbergen <ericvh@gmail.com>
> Cc: James Simmons <jsimmons@infradead.org>
> Cc: Latchesar Ionkov <lucho@ionkov.net>
> Cc: Oleg Drokin <oleg.drokin@intel.com>
> Cc: Ron Minnich <rminnich@sandia.gov>
> Cc: Trond Myklebust <trond.myklebust@primarydata.com>
> Cc: devel@driverdev.osuosl.org
> Cc: linux-nfs@vger.kernel.org
> Cc: linux-nvme@lists.infradead.org
> Cc: linux-rdma@vger.kernel.org
> Cc: lustre-devel@lists.lustre.org
> Cc: netdev@vger.kernel.org
> Cc: rds-devel@oss.oracle.com
> Cc: target-devel@vger.kernel.org
> Cc: v9fs-developer@lists.sourceforge.net
> ---
>  drivers/infiniband/core/mad.c                      |  28 +--
>  drivers/infiniband/core/rw.c                       |  30 ++-
>  drivers/infiniband/core/umem.c                     |   4 +-
>  drivers/infiniband/core/umem_odp.c                 |   6 +-
>  drivers/infiniband/hw/mlx4/cq.c                    |   2 +-
>  drivers/infiniband/hw/mlx4/mad.c                   |  28 +--
>  drivers/infiniband/hw/mlx4/mr.c                    |   4 +-
>  drivers/infiniband/hw/mlx4/qp.c                    |  10 +-
>  drivers/infiniband/hw/mlx5/mr.c                    |   4 +-

For mlx5 and mlx4 parts.
Acked-by: Leon Romanovsky <leonro@mellanox.com>

Thanks

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 169 bytes --]

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply

* [PATCH net-next] tools: psock_lib: harden socket filter used by psock tests
From: Sowmini Varadhan @ 2017-01-12 13:10 UTC (permalink / raw)
  To: netdev, sowmini.varadhan; +Cc: daniel, willemb, davem
In-Reply-To: <cover.1484060892.git.sowmini.varadhan@oracle.com>

The filter added by sock_setfilter is intended to only permit
packets matching the pattern set up by create_payload(), but
we only check the ip_len, and a single test-character in
the IP packet to ensure this condition.

Harden the filter by adding additional constraints so that we only
permit UDP/IPv4 packets that meet the ip_len and test-character
requirements. Include the bpf_asm src as a comment, in case this
needs to be enhanced in the future

Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
---
 tools/testing/selftests/net/psock_lib.h |   39 +++++++++++++++++++++++++-----
 1 files changed, 32 insertions(+), 7 deletions(-)

diff --git a/tools/testing/selftests/net/psock_lib.h b/tools/testing/selftests/net/psock_lib.h
index 24bc7ec..a77da88 100644
--- a/tools/testing/selftests/net/psock_lib.h
+++ b/tools/testing/selftests/net/psock_lib.h
@@ -40,14 +40,39 @@
 
 static __maybe_unused void sock_setfilter(int fd, int lvl, int optnum)
 {
+	/* the filter below checks for all of the following conditions that
+	 * are based on the contents of create_payload()
+	 *  ether type 0x800 and
+	 *  ip proto udp     and
+	 *  skb->len == DATA_LEN and
+	 *  udp[38] == 'a' or udp[38] == 'b'
+	 * It can be generated from the following bpf_asm input:
+	 *	ldh [12]
+	 *	jne #0x800, drop	; ETH_P_IP
+	 *	ldb [23]
+	 *	jneq #17, drop		; IPPROTO_UDP
+	 *	ld len			; ld skb->len
+	 *	jlt #100, drop		; DATA_LEN
+	 *	ldb [80]
+	 *	jeq #97, pass		; DATA_CHAR
+	 *	jne #98, drop		; DATA_CHAR_1
+	 *	pass:
+	 *	  ret #-1
+	 *	drop:
+	 *	  ret #0
+	 */
 	struct sock_filter bpf_filter[] = {
-		{ 0x80, 0, 0, 0x00000000 },  /* LD  pktlen		      */
-		{ 0x35, 0, 4, DATA_LEN   },  /* JGE DATA_LEN  [f goto nomatch]*/
-		{ 0x30, 0, 0, 0x00000050 },  /* LD  ip[80]		      */
-		{ 0x15, 1, 0, DATA_CHAR  },  /* JEQ DATA_CHAR   [t goto match]*/
-		{ 0x15, 0, 1, DATA_CHAR_1},  /* JEQ DATA_CHAR_1 [t goto match]*/
-		{ 0x06, 0, 0, 0x00000060 },  /* RET match	              */
-		{ 0x06, 0, 0, 0x00000000 },  /* RET no match		      */
+		{ 0x28,  0,  0, 0x0000000c },
+		{ 0x15,  0,  8, 0x00000800 },
+		{ 0x30,  0,  0, 0x00000017 },
+		{ 0x15,  0,  6, 0x00000011 },
+		{ 0x80,  0,  0, 0000000000 },
+		{ 0x35,  0,  4, 0x00000064 },
+		{ 0x30,  0,  0, 0x00000050 },
+		{ 0x15,  1,  0, 0x00000061 },
+		{ 0x15,  0,  1, 0x00000062 },
+		{ 0x06,  0,  0, 0xffffffff },
+		{ 0x06,  0,  0, 0000000000 },
 	};
 	struct sock_fprog bpf_prog;
 
-- 
1.7.1

^ permalink raw reply related

* Re: [PATCH net-next] net/mlx5e: Support bpf_xdp_adjust_head()
From: Saeed Mahameed @ 2017-01-12 13:10 UTC (permalink / raw)
  To: Martin KaFai Lau
  Cc: Linux Netdev List, Saeed Mahameed, Tariq Toukan, Kernel Team
In-Reply-To: <1484186975-1862468-1-git-send-email-kafai@fb.com>

On Thu, Jan 12, 2017 at 4:09 AM, Martin KaFai Lau <kafai@fb.com> wrote:
> This patch adds bpf_xdp_adjust_head() support to mlx5e.

Hi Martin, Thanks for the patch !

you can find some comments below.

>
> 1. rx_headroom is added to struct mlx5e_rq.  It uses
>    an existing 4 byte hole in the struct.
> 2. The adjusted data length is checked against
>    MLX5E_XDP_MIN_INLINE and MLX5E_SW2HW_MTU(rq->netdev->mtu).
> 3. The macro MLX5E_SW2HW_MTU is moved from en_main.c to en.h.
>    MLX5E_HW2SW_MTU is also moved to en.h for symmetric reason
>    but it is not a must.
>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
> ---
>  drivers/net/ethernet/mellanox/mlx5/core/en.h      |  4 ++
>  drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 18 +++----
>  drivers/net/ethernet/mellanox/mlx5/core/en_rx.c   | 63 ++++++++++++++---------
>  3 files changed, 51 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h b/drivers/net/ethernet/mellanox/mlx5/core/en.h
> index a473cea10c16..0d9dd860a295 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
> @@ -51,6 +51,9 @@
>
>  #define MLX5_SET_CFG(p, f, v) MLX5_SET(create_flow_group_in, p, f, v)
>
> +#define MLX5E_HW2SW_MTU(hwmtu) ((hwmtu) - (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN))
> +#define MLX5E_SW2HW_MTU(swmtu) ((swmtu) + (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN))
> +
>  #define MLX5E_MAX_NUM_TC       8
>
>  #define MLX5E_PARAMS_MINIMUM_LOG_SQ_SIZE                0x6
> @@ -369,6 +372,7 @@ struct mlx5e_rq {
>
>         unsigned long          state;
>         int                    ix;
> +       u16                    rx_headroom;
>
>         struct mlx5e_rx_am     am; /* Adaptive Moderation */
>         struct bpf_prog       *xdp_prog;
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> index f74ba73c55c7..aba3691e0919 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> @@ -343,9 +343,6 @@ static void mlx5e_disable_async_events(struct mlx5e_priv *priv)
>         synchronize_irq(mlx5_get_msix_vec(priv->mdev, MLX5_EQ_VEC_ASYNC));
>  }
>
> -#define MLX5E_HW2SW_MTU(hwmtu) (hwmtu - (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN))
> -#define MLX5E_SW2HW_MTU(swmtu) (swmtu + (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN))
> -
>  static inline int mlx5e_get_wqe_mtt_sz(void)
>  {
>         /* UMR copies MTTs in units of MLX5_UMR_MTT_ALIGNMENT bytes.
> @@ -534,9 +531,13 @@ static int mlx5e_create_rq(struct mlx5e_channel *c,
>                 goto err_rq_wq_destroy;
>         }
>
> -       rq->buff.map_dir = DMA_FROM_DEVICE;
> -       if (rq->xdp_prog)
> +       if (rq->xdp_prog) {
>                 rq->buff.map_dir = DMA_BIDIRECTIONAL;
> +               rq->rx_headroom = XDP_PACKET_HEADROOM;
> +       } else {
> +               rq->buff.map_dir = DMA_FROM_DEVICE;
> +               rq->rx_headroom = MLX5_RX_HEADROOM;
> +       }
>
>         switch (priv->params.rq_wq_type) {
>         case MLX5_WQ_TYPE_LINKED_LIST_STRIDING_RQ:
> @@ -586,7 +587,7 @@ static int mlx5e_create_rq(struct mlx5e_channel *c,
>                 byte_count = rq->buff.wqe_sz;
>
>                 /* calc the required page order */
> -               frag_sz = MLX5_RX_HEADROOM +
> +               frag_sz = rq->rx_headroom +
>                           byte_count /* packet data */ +
>                           SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
>                 frag_sz = SKB_DATA_ALIGN(frag_sz);
> @@ -3153,11 +3154,6 @@ static int mlx5e_xdp_set(struct net_device *netdev, struct bpf_prog *prog)
>         bool reset, was_opened;
>         int i;
>
> -       if (prog && prog->xdp_adjust_head) {
> -               netdev_err(netdev, "Does not support bpf_xdp_adjust_head()\n");
> -               return -EOPNOTSUPP;
> -       }
> -
>         mutex_lock(&priv->state_lock);
>
>         if ((netdev->features & NETIF_F_LRO) && prog) {
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
> index 0e2fb3ed1790..914e00132e08 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
> @@ -264,7 +264,7 @@ int mlx5e_alloc_rx_wqe(struct mlx5e_rq *rq, struct mlx5e_rx_wqe *wqe, u16 ix)
>         if (unlikely(mlx5e_page_alloc_mapped(rq, di)))
>                 return -ENOMEM;
>
> -       wqe->data.addr = cpu_to_be64(di->addr + MLX5_RX_HEADROOM);
> +       wqe->data.addr = cpu_to_be64(di->addr + rq->rx_headroom);
>         return 0;
>  }
>
> @@ -646,8 +646,7 @@ static inline void mlx5e_xmit_xdp_doorbell(struct mlx5e_sq *sq)
>
>  static inline void mlx5e_xmit_xdp_frame(struct mlx5e_rq *rq,
>                                         struct mlx5e_dma_info *di,
> -                                       unsigned int data_offset,
> -                                       int len)
> +                                       const struct xdp_buff *xdp)
>  {
>         struct mlx5e_sq          *sq   = &rq->channel->xdp_sq;
>         struct mlx5_wq_cyc       *wq   = &sq->wq;
> @@ -659,9 +658,17 @@ static inline void mlx5e_xmit_xdp_frame(struct mlx5e_rq *rq,
>         struct mlx5_wqe_eth_seg  *eseg = &wqe->eth;
>         struct mlx5_wqe_data_seg *dseg;
>
> +       ptrdiff_t data_offset = xdp->data - xdp->data_hard_start;
>         dma_addr_t dma_addr  = di->addr + data_offset + MLX5E_XDP_MIN_INLINE;
> -       unsigned int dma_len = len - MLX5E_XDP_MIN_INLINE;
> -       void *data           = page_address(di->page) + data_offset;
> +       unsigned int dma_len = xdp->data_end - xdp->data;
> +
> +       if (unlikely(dma_len < MLX5E_XDP_MIN_INLINE ||

I don't think this can happen, MLX5E_XDP_MIN_INLINE is 18 bytes and
should not get bigger in the future,
Also i don't think it is possible for XDP prog to xmit packets smaller
than 18 bytes, let's remove this

> +                    MLX5E_SW2HW_MTU(rq->netdev->mtu) < dma_len)) {
> +               rq->stats.xdp_drop++;
> +               mlx5e_page_release(rq, di, true);
> +               return;
> +       }
> +       dma_len -= MLX5E_XDP_MIN_INLINE;

Move this to after the below sanity check, it is better to separate
logic from pre-conditions

>
>         if (unlikely(!mlx5e_sq_has_room_for(sq, MLX5E_XDP_TX_WQEBBS))) {
>                 if (sq->db.xdp.doorbell) {
> @@ -680,7 +687,7 @@ static inline void mlx5e_xmit_xdp_frame(struct mlx5e_rq *rq,
>         memset(wqe, 0, sizeof(*wqe));
>
>         /* copy the inline part */
> -       memcpy(eseg->inline_hdr_start, data, MLX5E_XDP_MIN_INLINE);
> +       memcpy(eseg->inline_hdr_start, xdp->data, MLX5E_XDP_MIN_INLINE);
>         eseg->inline_hdr_sz = cpu_to_be16(MLX5E_XDP_MIN_INLINE);
>
>         dseg = (struct mlx5_wqe_data_seg *)cseg + (MLX5E_XDP_TX_DS_COUNT - 1);
> @@ -706,22 +713,16 @@ static inline void mlx5e_xmit_xdp_frame(struct mlx5e_rq *rq,
>  static inline bool mlx5e_xdp_handle(struct mlx5e_rq *rq,
>                                     const struct bpf_prog *prog,
>                                     struct mlx5e_dma_info *di,
> -                                   void *data, u16 len)
> +                                   struct xdp_buff *xdp)
>  {
> -       struct xdp_buff xdp;
>         u32 act;
>
> -       if (!prog)
> -               return false;
> -
> -       xdp.data = data;
> -       xdp.data_end = xdp.data + len;
> -       act = bpf_prog_run_xdp(prog, &xdp);
> +       act = bpf_prog_run_xdp(prog, xdp);
>         switch (act) {
>         case XDP_PASS:
>                 return false;
>         case XDP_TX:
> -               mlx5e_xmit_xdp_frame(rq, di, MLX5_RX_HEADROOM, len);
> +               mlx5e_xmit_xdp_frame(rq, di, xdp);
>                 return true;
>         default:
>                 bpf_warn_invalid_xdp_action(act);
> @@ -737,18 +738,19 @@ static inline
>  struct sk_buff *skb_from_cqe(struct mlx5e_rq *rq, struct mlx5_cqe64 *cqe,
>                              u16 wqe_counter, u32 cqe_bcnt)
>  {
> +       const struct bpf_prog *xdp_prog;
>         struct mlx5e_dma_info *di;
>         struct sk_buff *skb;
>         void *va, *data;
> -       bool consumed;
> +       u16 rx_headroom = rq->rx_headroom;
>
>         di             = &rq->dma_info[wqe_counter];
>         va             = page_address(di->page);
> -       data           = va + MLX5_RX_HEADROOM;
> +       data           = va + rx_headroom;
>
>         dma_sync_single_range_for_cpu(rq->pdev,
>                                       di->addr,
> -                                     MLX5_RX_HEADROOM,
> +                                     rx_headroom,
>                                       rq->buff.wqe_sz,
>                                       DMA_FROM_DEVICE);
>         prefetch(data);
> @@ -760,11 +762,26 @@ struct sk_buff *skb_from_cqe(struct mlx5e_rq *rq, struct mlx5_cqe64 *cqe,
>         }
>
>         rcu_read_lock();
> -       consumed = mlx5e_xdp_handle(rq, READ_ONCE(rq->xdp_prog), di, data,
> -                                   cqe_bcnt);
> +       xdp_prog = READ_ONCE(rq->xdp_prog);
> +       if (xdp_prog) {
> +               struct xdp_buff xdp;
> +               bool consumed;
> +
> +               xdp.data = data;
> +               xdp.data_end = xdp.data + cqe_bcnt;
> +               xdp.data_hard_start = va;
> +
> +               consumed = mlx5e_xdp_handle(rq, xdp_prog, di, &xdp);
> +
> +               if (consumed) {
> +                       rcu_read_unlock();
> +                       return NULL; /* page/packet was consumed by XDP */
> +               }
> +
> +               rx_headroom = xdp.data - xdp.data_hard_start;
> +               cqe_bcnt = xdp.data_end - xdp.data;
> +       }

This whole new logic belongs to mlx5e_xdp_handle, I would like to keep
xdp related code in one place.

move the xdp_buff initialization back to there and keep the xdp_prog
check in mlx5e_xdp_handle;
+      xdp_prog = READ_ONCE(rq->xdp_prog);
+       if (!xdp_prog)
+                    return false

you can remove "const struct bpf_prog *prog" parameter from
mlx5e_xdp_handle and take it directly from rq.

if you need va for xdp_buff you can pass it as a paramter to
mlx5e_xdp_handle  as well:
mlx5e_xdp_handle(rq, di, va, data, cqe_bcnt);
Make sense ?

>         rcu_read_unlock();
> -       if (consumed)
> -               return NULL; /* page/packet was consumed by XDP */
>
>         skb = build_skb(va, RQ_PAGE_SIZE(rq));
>         if (unlikely(!skb)) {
> @@ -777,7 +794,7 @@ struct sk_buff *skb_from_cqe(struct mlx5e_rq *rq, struct mlx5_cqe64 *cqe,
>         page_ref_inc(di->page);
>         mlx5e_page_release(rq, di, true);
>
> -       skb_reserve(skb, MLX5_RX_HEADROOM);
> +       skb_reserve(skb, rx_headroom);
>         skb_put(skb, cqe_bcnt);
>
>         return skb;
> --
> 2.5.1
>

^ permalink raw reply

* Re: [PATCH 8/9] IB: Convert ib_dma_*_coherent() argument type from u64 into dma_addr_t
From: Leon Romanovsky @ 2017-01-12 13:12 UTC (permalink / raw)
  To: Bart Van Assche
  Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, David S . Miller,
	netdev-u79uwXL29TY76Z2rM5mHXA, rds-devel-N0ozoZBvEnrZJqsBc5GL+g
In-Reply-To: <20170111005648.14988-9-bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]

On Tue, Jan 10, 2017 at 04:56:47PM -0800, Bart Van Assche wrote:
> This patch does not change any functionality.
>
> Signed-off-by: Bart Van Assche <bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
> Cc: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: rds-devel-N0ozoZBvEnrZJqsBc5GL+g@public.gmane.org
> ---
>  include/rdma/ib_verbs.h | 11 +++--------
>  net/rds/ib.h            |  6 +++---
>  2 files changed, 6 insertions(+), 11 deletions(-)
>

Thanks,
Reviewed-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply

* Re: [PATCH v3 net-next 4/4] syncookies: use SipHash in place of SHA1
From: Eric Dumazet @ 2017-01-12 13:17 UTC (permalink / raw)
  To: Jason A. Donenfeld
  Cc: davem, ebiggers3, jeanphilippe.aumasson, gregkh, netdev,
	linux-kernel
In-Reply-To: <20170108125403.16355-5-Jason@zx2c4.com>

On Sun, 2017-01-08 at 13:54 +0100, Jason A. Donenfeld wrote:
> SHA1 is slower and less secure than SipHash, and so replacing syncookie
> generation with SipHash makes natural sense. Some BSDs have been doing
> this for several years in fact.
> 
> The speedup should be similar -- and even more impressive -- to the
> speedup from the sequence number fix in this series.

I confirm a nice speedup under SYNFLOOD.

sha_transform() used to consume ~12 % of cpu cycles, while the
siphash_2u64() only uses ~1.9 %

Depending on the setup, gain is about 9 %

     4.48%  [kernel]  [k] ipt_do_table                   
     4.39%  [kernel]  [k] fib_table_lookup               
     3.90%  [kernel]  [k] __netif_receive_skb_core       
     3.76%  [kernel]  [k] fib_rules_lookup               
     3.15%  [kernel]  [k] __inet_lookup_established      
     3.11%  [kernel]  [k] tcp_conn_request               
     2.51%  [kernel]  [k] tcp_v4_rcv                     
     2.42%  [kernel]  [k] tcp_make_synack                
     2.22%  [kernel]  [k] nf_iterate                     
     2.16%  [kernel]  [k] ip_rcv                         
     1.92%  [kernel]  [k] siphash_2u64                   
     1.76%  [kernel]  [k] __ip_route_output_key          
     1.73%  [kernel]  [k] mlx4_en_process_rx_cq          
     1.68%  [kernel]  [k] memcpy_erms                    
     1.59%  [kernel]  [k] __alloc_skb                    
     1.49%  [kernel]  [k] __dev_queue_xmit               
     1.48%  [kernel]  [k] kmem_cache_alloc               
     1.38%  [kernel]  [k] __local_bh_enable_ip           
     1.36%  [kernel]  [k] kmem_cache_free                
     1.21%  [kernel]  [k] ___cache_free                  
     1.09%  [kernel]  [k] __build_skb                    
     1.07%  [kernel]  [k] inet_reqsk_alloc               
     1.04%  [kernel]  [k] kfree                          
     1.04%  [kernel]  [k] ip_build_and_send_pkt          
     1.04%  [kernel]  [k] inet_gro_receive               
     1.01%  [kernel]  [k] fib_validate_source            
     0.98%  [kernel]  [k] tcp_openreq_init_rwin          
     0.98%  [kernel]  [k] inet_csk_route_req             
     0.97%  [kernel]  [k] fib_get_table                  
     0.96%  [kernel]  [k] ip_finish_output2              
     0.94%  [kernel]  [k] tcp_v4_do_rcv                  
     0.91%  [kernel]  [k] ip_local_deliver_finish        
     0.91%  [kernel]  [k] netif_skb_features             
     0.91%  [kernel]  [k] dev_hard_start_xmit         

^ permalink raw reply

* Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings
From: Simon Horman @ 2017-01-12 13:18 UTC (permalink / raw)
  To: Sergei Shtylyov; +Cc: David Miller, Magnus Damm, netdev, linux-renesas-soc
In-Reply-To: <3e1d4324-4288-8d65-56fd-8c3e7283020b@cogentembedded.com>

On Thu, Jan 12, 2017 at 03:03:05PM +0300, Sergei Shtylyov wrote:
> On 01/12/2017 12:11 PM, Simon Horman wrote:

...

> >>   Here, it stop once an untransmitted buffer is encountered...
> >
> >Yes, I see that now.
> >
> >I wonder if we should:
> >
> >a) paramatise ravb_tx_free() so it may either clear all transmitted buffers
> >   (current behaviour) or all buffers (new behaviour).
> >b) provide a different version of this loop in ravb_ring_free()
> >
> >What are your thoughts?
> 
>    I'm voting for (b).

Ok, something like this?

@@ -215,6 +225,30 @@ static void ravb_ring_free(struct net_device *ndev, int q)
 	}
 
 	if (priv->tx_ring[q]) {
+		for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; priv->dirty_tx[q]++) {
+			struct ravb_tx_desc *desc;
+			int entry;
+
+			entry = priv->dirty_tx[q] % (priv->num_tx_ring[q] *
+						     NUM_TX_DESC);
+			desc = &priv->tx_ring[q][entry];
+
+			/* Free the original skb. */
+			if (priv->tx_skb[q][entry / NUM_TX_DESC]) {
+				u32 size = le16_to_cpu(desc->ds_tagl) & TX_DS;
+
+				dma_unmap_single(ndev->dev.parent,
+						 le32_to_cpu(desc->dptr),
+						 size, DMA_TO_DEVICE);
+				/* Last packet descriptor? */
+				if (entry % NUM_TX_DESC == NUM_TX_DESC - 1) {
+					entry /= NUM_TX_DESC;
+					dev_kfree_skb_any(priv->tx_skb[q][entry]);
+					priv->tx_skb[q][entry] = NULL;
+				}
+			}
+		}
+
 		ring_size = sizeof(struct ravb_tx_desc) *
 			    (priv->num_tx_ring[q] * NUM_TX_DESC + 1);
 		dma_free_coherent(ndev->dev.parent, ring_size, priv->tx_ring[q],

^ permalink raw reply

* [PATCH net] mld: do not remove mld souce list info when set link down
From: Hangbin Liu @ 2017-01-12 13:19 UTC (permalink / raw)
  To: netdev; +Cc: David Miller, Hangbin Liu

This is an IPv6 version of commit 24803f38a5c0 ("igmp: do not remove igmp
souce list..."). In mld_del_delrec(), we will restore back all source filter
info instead of flush them.

Move mld_clear_delrec() from ipv6_mc_down() to ipv6_mc_destroy_dev() since
we should not remove source list info when set link down. Remove
igmp6_group_dropped() in ipv6_mc_destroy_dev() since we have called it in
ipv6_mc_down().

Also clear all source info after igmp6_group_dropped() instead of in it
because ipv6_mc_down() will call igmp6_group_dropped().

Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
 net/ipv6/mcast.c | 51 ++++++++++++++++++++++++++++++---------------------
 1 file changed, 30 insertions(+), 21 deletions(-)

diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 14a3903..7139fff 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -81,7 +81,7 @@ static void mld_gq_timer_expire(unsigned long data);
 static void mld_ifc_timer_expire(unsigned long data);
 static void mld_ifc_event(struct inet6_dev *idev);
 static void mld_add_delrec(struct inet6_dev *idev, struct ifmcaddr6 *pmc);
-static void mld_del_delrec(struct inet6_dev *idev, const struct in6_addr *addr);
+static void mld_del_delrec(struct inet6_dev *idev, struct ifmcaddr6 *pmc);
 static void mld_clear_delrec(struct inet6_dev *idev);
 static bool mld_in_v1_mode(const struct inet6_dev *idev);
 static int sf_setstate(struct ifmcaddr6 *pmc);
@@ -692,9 +692,9 @@ static void igmp6_group_dropped(struct ifmcaddr6 *mc)
 			dev_mc_del(dev, buf);
 	}
 
-	if (mc->mca_flags & MAF_NOREPORT)
-		goto done;
 	spin_unlock_bh(&mc->mca_lock);
+	if (mc->mca_flags & MAF_NOREPORT)
+		return;
 
 	if (!mc->idev->dead)
 		igmp6_leave_group(mc);
@@ -702,8 +702,6 @@ static void igmp6_group_dropped(struct ifmcaddr6 *mc)
 	spin_lock_bh(&mc->mca_lock);
 	if (del_timer(&mc->mca_timer))
 		atomic_dec(&mc->mca_refcnt);
-done:
-	ip6_mc_clear_src(mc);
 	spin_unlock_bh(&mc->mca_lock);
 }
 
@@ -748,10 +746,11 @@ static void mld_add_delrec(struct inet6_dev *idev, struct ifmcaddr6 *im)
 	spin_unlock_bh(&idev->mc_lock);
 }
 
-static void mld_del_delrec(struct inet6_dev *idev, const struct in6_addr *pmca)
+static void mld_del_delrec(struct inet6_dev *idev, struct ifmcaddr6 *im)
 {
 	struct ifmcaddr6 *pmc, *pmc_prev;
-	struct ip6_sf_list *psf, *psf_next;
+	struct ip6_sf_list *psf;
+	struct in6_addr *pmca = &im->mca_addr;
 
 	spin_lock_bh(&idev->mc_lock);
 	pmc_prev = NULL;
@@ -768,14 +767,20 @@ static void mld_del_delrec(struct inet6_dev *idev, const struct in6_addr *pmca)
 	}
 	spin_unlock_bh(&idev->mc_lock);
 
+	spin_lock_bh(&im->mca_lock);
 	if (pmc) {
-		for (psf = pmc->mca_tomb; psf; psf = psf_next) {
-			psf_next = psf->sf_next;
-			kfree(psf);
+		im->idev = pmc->idev;
+		im->mca_crcount = idev->mc_qrv;
+		im->mca_sfmode = pmc->mca_sfmode;
+		if (pmc->mca_sfmode == MCAST_INCLUDE) {
+			im->mca_tomb = pmc->mca_tomb;
+			im->mca_sources = pmc->mca_sources;
+			for (psf = im->mca_sources; psf; psf = psf->sf_next)
+				psf->sf_crcount = im->mca_crcount;
 		}
 		in6_dev_put(pmc->idev);
-		kfree(pmc);
 	}
+	spin_unlock_bh(&im->mca_lock);
 }
 
 static void mld_clear_delrec(struct inet6_dev *idev)
@@ -904,7 +909,7 @@ int ipv6_dev_mc_inc(struct net_device *dev, const struct in6_addr *addr)
 	mca_get(mc);
 	write_unlock_bh(&idev->lock);
 
-	mld_del_delrec(idev, &mc->mca_addr);
+	mld_del_delrec(idev, mc);
 	igmp6_group_added(mc);
 	ma_put(mc);
 	return 0;
@@ -927,6 +932,7 @@ int __ipv6_dev_mc_dec(struct inet6_dev *idev, const struct in6_addr *addr)
 				write_unlock_bh(&idev->lock);
 
 				igmp6_group_dropped(ma);
+				ip6_mc_clear_src(ma);
 
 				ma_put(ma);
 				return 0;
@@ -2501,15 +2507,17 @@ void ipv6_mc_down(struct inet6_dev *idev)
 	/* Withdraw multicast list */
 
 	read_lock_bh(&idev->lock);
-	mld_ifc_stop_timer(idev);
-	mld_gq_stop_timer(idev);
-	mld_dad_stop_timer(idev);
 
 	for (i = idev->mc_list; i; i = i->next)
 		igmp6_group_dropped(i);
-	read_unlock_bh(&idev->lock);
 
-	mld_clear_delrec(idev);
+	/* Should stop timer after group drop. or we will
+	 * start timer again in mld_ifc_event()
+	 */
+	mld_ifc_stop_timer(idev);
+	mld_gq_stop_timer(idev);
+	mld_dad_stop_timer(idev);
+	read_unlock_bh(&idev->lock);
 }
 
 static void ipv6_mc_reset(struct inet6_dev *idev)
@@ -2531,8 +2539,10 @@ void ipv6_mc_up(struct inet6_dev *idev)
 
 	read_lock_bh(&idev->lock);
 	ipv6_mc_reset(idev);
-	for (i = idev->mc_list; i; i = i->next)
+	for (i = idev->mc_list; i; i = i->next) {
+		mld_del_delrec(idev, i);
 		igmp6_group_added(i);
+	}
 	read_unlock_bh(&idev->lock);
 }
 
@@ -2565,6 +2575,7 @@ void ipv6_mc_destroy_dev(struct inet6_dev *idev)
 
 	/* Deactivate timers */
 	ipv6_mc_down(idev);
+	mld_clear_delrec(idev);
 
 	/* Delete all-nodes address. */
 	/* We cannot call ipv6_dev_mc_dec() directly, our caller in
@@ -2579,11 +2590,9 @@ void ipv6_mc_destroy_dev(struct inet6_dev *idev)
 	write_lock_bh(&idev->lock);
 	while ((i = idev->mc_list) != NULL) {
 		idev->mc_list = i->next;
-		write_unlock_bh(&idev->lock);
 
-		igmp6_group_dropped(i);
+		write_unlock_bh(&idev->lock);
 		ma_put(i);
-
 		write_lock_bh(&idev->lock);
 	}
 	write_unlock_bh(&idev->lock);
-- 
2.5.5

^ permalink raw reply related

* Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings
From: Lino Sanfilippo @ 2017-01-12 13:23 UTC (permalink / raw)
  To: Simon Horman, Sergei Shtylyov
  Cc: David Miller, Magnus Damm, netdev, linux-renesas-soc
In-Reply-To: <20170112091116.GC7724@verge.net.au>

Hi,

On 12.01.2017 10:11, Simon Horman wrote:

>>> +
>>> +	for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; priv->dirty_tx[q]++) {

BTW: How can this work correctly when cur_tx wraps and dirty_tx is greater?

Regards,
Lino

^ permalink raw reply

* [PATCH net-next] IPsec: do not ignore crypto err in ah input
From: Gilad Ben-Yossef @ 2017-01-12 13:33 UTC (permalink / raw)
  To: steffen.klassert, herbert, davem, netdev
  Cc: ofir.drang, gilad.benyossef, Gilad Ben-Yossef

ah input processing uses the asynchrnous hash crypto API which
supplies an error code as part of the operation completion but 
the error code was being ignored.

Treat a crypto API error indication as a verification failure.

While a crypto API reported error would almost certainly result
in a memcpy of the digest failing anyway and thus the security
risk seems minor, performing a memory compare on what might be
uninitialized memory is wrong.

Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
---

The change was boot tested on Arm64 but I did not exercise
the specific error code path in question.

 net/ipv4/ah4.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/ipv4/ah4.c b/net/ipv4/ah4.c
index f2a7102..22377c8 100644
--- a/net/ipv4/ah4.c
+++ b/net/ipv4/ah4.c
@@ -270,6 +270,9 @@ static void ah_input_done(struct crypto_async_request *base, int err)
 	int ihl = ip_hdrlen(skb);
 	int ah_hlen = (ah->hdrlen + 2) << 2;
 
+	if (err)
+		goto out;
+
 	work_iph = AH_SKB_CB(skb)->tmp;
 	auth_data = ah_tmp_auth(work_iph, ihl);
 	icv = ah_tmp_icv(ahp->ahash, auth_data, ahp->icv_trunc_len);
-- 
2.1.4

^ permalink raw reply related

* [PATCH net-next] cdc-ether: usbnet_cdc_zte_status() can be static
From: Wei Yongjun @ 2017-01-12 13:43 UTC (permalink / raw)
  To: Oliver Neukum; +Cc: Wei Yongjun, linux-usb, netdev

From: Wei Yongjun <weiyongjun1@huawei.com>

Fixes the following sparse warning:

drivers/net/usb/cdc_ether.c:469:6: warning:
 symbol 'usbnet_cdc_zte_status' was not declared. Should it be static?

Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
 drivers/net/usb/cdc_ether.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index fe7b288..620ba8e 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -466,7 +466,7 @@ static int usbnet_cdc_zte_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
  * connected. This causes the link state to be incorrect. Work around this by
  * always setting the state to off, then on.
  */
-void usbnet_cdc_zte_status(struct usbnet *dev, struct urb *urb)
+static void usbnet_cdc_zte_status(struct usbnet *dev, struct urb *urb)
 {
 	struct usb_cdc_notification *event;

^ permalink raw reply related

* [PATCH iproute2 v4 1/4] ifstat: Includes reorder
From: Nogah Frankel @ 2017-01-12 13:49 UTC (permalink / raw)
  To: netdev
  Cc: stephen, roszenrami, roopa, jiri, idosch, eladr, yotamg, ogerlitz,
	Nogah Frankel
In-Reply-To: <1484228991-32999-1-git-send-email-nogahf@mellanox.com>

Reorder the includes order in misc/ifstat.c to match convention.

Signed-off-by: Nogah Frankel <nogahf@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
---
 misc/ifstat.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/misc/ifstat.c b/misc/ifstat.c
index 92d67b0..5bcbcc8 100644
--- a/misc/ifstat.c
+++ b/misc/ifstat.c
@@ -28,12 +28,12 @@
 #include <math.h>
 #include <getopt.h>
 
-#include <libnetlink.h>
-#include <json_writer.h>
 #include <linux/if.h>
 #include <linux/if_link.h>
 
-#include <SNAPSHOT.h>
+#include "libnetlink.h"
+#include "json_writer.h"
+#include "SNAPSHOT.h"
 
 int dump_zeros;
 int reset_history;
-- 
2.4.3

^ permalink raw reply related

* [PATCH iproute2 v4 4/4] ifstat: Add "sw only" extended statistics to ifstat
From: Nogah Frankel @ 2017-01-12 13:49 UTC (permalink / raw)
  To: netdev
  Cc: stephen, roszenrami, roopa, jiri, idosch, eladr, yotamg, ogerlitz,
	Nogah Frankel
In-Reply-To: <1484228991-32999-1-git-send-email-nogahf@mellanox.com>

Add support for extended statistics of SW only type, for counting only the
packets that went via the cpu. (useful for systems with forward
offloading). It reads it from filter type IFLA_STATS_LINK_OFFLOAD_XSTATS
and sub type IFLA_OFFLOAD_XSTATS_CPU_HIT.

It is under the name 'cpu_hits'
(or any shorten of it as 'cpu' or simply 'c')

For example:
ifstat -x c

Signed-off-by: Nogah Frankel <nogahf@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
---
 misc/ifstat.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/misc/ifstat.c b/misc/ifstat.c
index 3478f0a..5b6a36b 100644
--- a/misc/ifstat.c
+++ b/misc/ifstat.c
@@ -730,7 +730,8 @@ static void xstat_usage(void)
 {
 	fprintf(stderr,
 "Usage: ifstat supported xstats:\n"
-"       64bits         default stats, with 64 bits support\n");
+"       64bits         default stats, with 64 bits support\n"
+"       cpu_hits       Counts only packets that went via the CPU.\n");
 }
 
 struct extended_stats_options_t {
@@ -745,6 +746,7 @@ struct extended_stats_options_t {
  */
 static const struct extended_stats_options_t extended_stats_options[] = {
 	{"64bits", IFLA_STATS_LINK_64, NO_SUB_TYPE},
+	{"cpu_hits",  IFLA_STATS_LINK_OFFLOAD_XSTATS, IFLA_OFFLOAD_XSTATS_CPU_HIT},
 };
 
 static const char *get_filter_type(const char *name)
-- 
2.4.3

^ permalink raw reply related

* [PATCH iproute2 v4 3/4] ifstat: Add 64 bits based stats to extended statistics
From: Nogah Frankel @ 2017-01-12 13:49 UTC (permalink / raw)
  To: netdev
  Cc: stephen, roszenrami, roopa, jiri, idosch, eladr, yotamg, ogerlitz,
	Nogah Frankel
In-Reply-To: <1484228991-32999-1-git-send-email-nogahf@mellanox.com>

The default stats for ifstat are 32 bits based.
The kernel supports 64 bits based stats. (They are returned in struct
rtnl_link_stats64 which is an exact copy of struct rtnl_link_stats, in
which the "normal" stats are returned, but with fields of u64 instead of
u32). This patch adds them as an extended stats.

It is read with filter type IFLA_STATS_LINK_64 and no sub type.

It is under the name 64bits
(or any shorten of it as "64")

For example:
ifstat -x 64bit

Signed-off-by: Nogah Frankel <nogahf@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
---
 misc/ifstat.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/misc/ifstat.c b/misc/ifstat.c
index 9467119..3478f0a 100644
--- a/misc/ifstat.c
+++ b/misc/ifstat.c
@@ -729,7 +729,8 @@ static int verify_forging(int fd)
 static void xstat_usage(void)
 {
 	fprintf(stderr,
-"Usage: ifstat supported xstats:\n");
+"Usage: ifstat supported xstats:\n"
+"       64bits         default stats, with 64 bits support\n");
 }
 
 struct extended_stats_options_t {
@@ -743,6 +744,7 @@ struct extended_stats_options_t {
  * Name length must be under 64 chars.
  */
 static const struct extended_stats_options_t extended_stats_options[] = {
+	{"64bits", IFLA_STATS_LINK_64, NO_SUB_TYPE},
 };
 
 static const char *get_filter_type(const char *name)
-- 
2.4.3

^ permalink raw reply related

* [PATCH iproute2 v4 0/4] update ifstat for new stats
From: Nogah Frankel @ 2017-01-12 13:49 UTC (permalink / raw)
  To: netdev
  Cc: stephen, roszenrami, roopa, jiri, idosch, eladr, yotamg, ogerlitz,
	Nogah Frankel

Previously stats were gotten by RTM_GETLINK which returns 32 bits based
statistics. It supports only one type of stats.
Lately, a new method to get stats was added - RTM_GETSTATS. It supports
ability to choose stats type. The basic stats were changed from 32 bits
based to 64 bits based.

This patchset adds ifstat the ability to get extended stats by this
method. Its adds two types of extended stats:
64bits - the same as the "normal" stats but get the stats from the cpu
in 64 bits based struct.
cpu_hits - for packets that hit cpu.

---
v3->v4:
- patch 2/4:
 - change xstat name read to avoid redundant copy.
 - delete extra line
- patch 4/4:
 - change xstat name.

v2->v3:
- patch 1/4:
 - add a new patch to reorder includes in misc/ifstat.c
- patch 2/4: (previously 1/3)
 - fix typos.
 - change error print to use fprintf.

v1->v2:
 - change from using RTM_GETSTATS always to using it only for extended
   stats.
 - Add 64bits extended stats type.

Nogah Frankel (4):
  ifstat: Includes reorder
  ifstat: Add extended statistics to ifstat
  ifstat: Add 64 bits based stats to extended statistics
  ifstat: Add "sw only" extended statistics to ifstat

 misc/ifstat.c | 170 +++++++++++++++++++++++++++++++++++++++++++++++++++-------
 1 file changed, 152 insertions(+), 18 deletions(-)

-- 
2.4.3

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox