* [PATCH net-next 08/11] net: hns3: print the ret value in error information
From: Peng Li @ 2018-06-28 4:12 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, linuxarm, yisen.zhuang, salil.mehta,
lipeng321
In-Reply-To: <1530159149-122284-1-git-send-email-lipeng321@huawei.com>
Print the ret value in error information can help find the reason.
Signed-off-by: Peng Li <lipeng321@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hnae3.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.c b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
index 3e5c83f..1a02620 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
@@ -94,7 +94,7 @@ static int hnae3_match_n_instantiate(struct hnae3_client *client,
ret = ae_dev->ops->init_client_instance(client, ae_dev);
if (ret) {
dev_err(&ae_dev->pdev->dev,
- "fail to instantiate client\n");
+ "fail to instantiate client, ret = %d\n", ret);
return ret;
}
@@ -134,7 +134,8 @@ int hnae3_register_client(struct hnae3_client *client)
ret = hnae3_match_n_instantiate(client, ae_dev, true);
if (ret)
dev_err(&ae_dev->pdev->dev,
- "match and instantiation failed for port\n");
+ "match and instantiation failed for port, ret = %d\n",
+ ret);
}
exit:
@@ -184,7 +185,8 @@ void hnae3_register_ae_algo(struct hnae3_ae_algo *ae_algo)
ae_dev->ops = ae_algo->ops;
ret = ae_algo->ops->init_ae_dev(ae_dev);
if (ret) {
- dev_err(&ae_dev->pdev->dev, "init ae_dev error.\n");
+ dev_err(&ae_dev->pdev->dev,
+ "init ae_dev error, ret = %d\n", ret);
continue;
}
@@ -197,7 +199,8 @@ void hnae3_register_ae_algo(struct hnae3_ae_algo *ae_algo)
ret = hnae3_match_n_instantiate(client, ae_dev, true);
if (ret)
dev_err(&ae_dev->pdev->dev,
- "match and instantiation failed\n");
+ "match and instantiation failed, ret = %d\n",
+ ret);
}
}
@@ -270,7 +273,8 @@ void hnae3_register_ae_dev(struct hnae3_ae_dev *ae_dev)
/* ae_dev init should set flag */
ret = ae_dev->ops->init_ae_dev(ae_dev);
if (ret) {
- dev_err(&ae_dev->pdev->dev, "init ae_dev error\n");
+ dev_err(&ae_dev->pdev->dev,
+ "init ae_dev error, ret = %d\n", ret);
goto out_err;
}
@@ -285,7 +289,8 @@ void hnae3_register_ae_dev(struct hnae3_ae_dev *ae_dev)
ret = hnae3_match_n_instantiate(client, ae_dev, true);
if (ret)
dev_err(&ae_dev->pdev->dev,
- "match and instantiation failed\n");
+ "match and instantiation failed, ret = %d\n",
+ ret);
}
out_err:
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 09/11] net: hns3: remove the Redundant put_vector in hns3_client_uninit
From: Peng Li @ 2018-06-28 4:12 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, linuxarm, yisen.zhuang, salil.mehta,
lipeng321
In-Reply-To: <1530159149-122284-1-git-send-email-lipeng321@huawei.com>
The interface h->ae_algo->ops->put_vector is called in both
hns3_nic_dealloc_vector_data and hns3_nic_uninit_vector_data in
hns3_client_uninit, this will cause vector freed twice.
This patch remove the Redundant put_vector to make vector freed
only once.
Signed-off-by: Peng Li <lipeng321@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 1a68952..beca364 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2745,10 +2745,6 @@ static int hns3_nic_uninit_vector_data(struct hns3_nic_priv *priv)
if (ret)
return ret;
- ret = h->ae_algo->ops->put_vector(h, tqp_vector->vector_irq);
- if (ret)
- return ret;
-
hns3_free_vector_ring_chain(tqp_vector, &vector_ring_chain);
if (priv->tqp_vector[i].irq_init_flag == HNS3_VECTOR_INITED) {
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 11/11] net: hns3: use lower_32_bits and upper_32_bits
From: Peng Li @ 2018-06-28 4:12 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, linuxarm, yisen.zhuang, salil.mehta,
lipeng321
In-Reply-To: <1530159149-122284-1-git-send-email-lipeng321@huawei.com>
From: Huazhong Tan <tanhuazhong@huawei.com>
MACRO lower_32_bits and upper_32_bits can help to get bits 0-31
and bits 32-63 of a number, so just use it.
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
index 7049d0b..383ecf0 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
@@ -123,9 +123,9 @@ static void hclge_cmd_config_regs(struct hclge_cmq_ring *ring)
if (ring->flag == HCLGE_TYPE_CSQ) {
hclge_write_dev(hw, HCLGE_NIC_CSQ_BASEADDR_L_REG,
- (u32)dma);
+ lower_32_bits(dma));
hclge_write_dev(hw, HCLGE_NIC_CSQ_BASEADDR_H_REG,
- (u32)((dma >> 31) >> 1));
+ upper_32_bits(dma));
hclge_write_dev(hw, HCLGE_NIC_CSQ_DEPTH_REG,
(ring->desc_num >> HCLGE_NIC_CMQ_DESC_NUM_S) |
HCLGE_NIC_CMQ_ENABLE);
@@ -133,9 +133,9 @@ static void hclge_cmd_config_regs(struct hclge_cmq_ring *ring)
hclge_write_dev(hw, HCLGE_NIC_CSQ_HEAD_REG, 0);
} else {
hclge_write_dev(hw, HCLGE_NIC_CRQ_BASEADDR_L_REG,
- (u32)dma);
+ lower_32_bits(dma));
hclge_write_dev(hw, HCLGE_NIC_CRQ_BASEADDR_H_REG,
- (u32)((dma >> 31) >> 1));
+ upper_32_bits(dma));
hclge_write_dev(hw, HCLGE_NIC_CRQ_DEPTH_REG,
(ring->desc_num >> HCLGE_NIC_CMQ_DESC_NUM_S) |
HCLGE_NIC_CMQ_ENABLE);
--
2.9.3
^ permalink raw reply related
* [PATCH v2 net-next] tcp: add new SNMP counter for drops when try to queue in rcv queue
From: Yafang Shao @ 2018-06-28 4:22 UTC (permalink / raw)
To: edumazet; +Cc: davem, netdev, linux-kernel, Yafang Shao
When sk_rmem_alloc is larger than the receive buffer and we can't
schedule more memory for it, the skb will be dropped.
In above situation, if this skb is put into the ofo queue,
LINUX_MIB_TCPOFODROP is incremented to track it.
While if this skb is put into the receive queue, there's no record.
So a new SNMP counter is introduced to track this behavior.
LINUX_MIB_TCPRCVQDROP: Number of packets meant to be queued in rcv queue
but dropped because socket rcvbuf limit hit.
Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
---
include/uapi/linux/snmp.h | 1 +
net/ipv4/proc.c | 1 +
net/ipv4/tcp_input.c | 8 ++++++--
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/snmp.h b/include/uapi/linux/snmp.h
index 97517f3..e5ebc83 100644
--- a/include/uapi/linux/snmp.h
+++ b/include/uapi/linux/snmp.h
@@ -280,6 +280,7 @@ enum
LINUX_MIB_TCPDELIVEREDCE, /* TCPDeliveredCE */
LINUX_MIB_TCPACKCOMPRESSED, /* TCPAckCompressed */
LINUX_MIB_TCPZEROWINDOWDROP, /* TCPZeroWindowDrop */
+ LINUX_MIB_TCPRCVQDROP, /* TCPRcvQDrop */
__LINUX_MIB_MAX
};
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index 225ef34..b46e4cf 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -288,6 +288,7 @@ static int sockstat_seq_show(struct seq_file *seq, void *v)
SNMP_MIB_ITEM("TCPDeliveredCE", LINUX_MIB_TCPDELIVEREDCE),
SNMP_MIB_ITEM("TCPAckCompressed", LINUX_MIB_TCPACKCOMPRESSED),
SNMP_MIB_ITEM("TCPZeroWindowDrop", LINUX_MIB_TCPZEROWINDOWDROP),
+ SNMP_MIB_ITEM("TCPRcvQDrop", LINUX_MIB_TCPRCVQDROP),
SNMP_MIB_SENTINEL
};
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 9c5b341..eecd359 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4611,8 +4611,10 @@ int tcp_send_rcvq(struct sock *sk, struct msghdr *msg, size_t size)
skb->data_len = data_len;
skb->len = size;
- if (tcp_try_rmem_schedule(sk, skb, skb->truesize))
+ if (tcp_try_rmem_schedule(sk, skb, skb->truesize)) {
+ NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPRCVQDROP);
goto err_free;
+ }
err = skb_copy_datagram_from_iter(skb, 0, &msg->msg_iter, size);
if (err)
@@ -4677,8 +4679,10 @@ static void tcp_data_queue(struct sock *sk, struct sk_buff *skb)
queue_and_out:
if (skb_queue_len(&sk->sk_receive_queue) == 0)
sk_forced_mem_schedule(sk, skb->truesize);
- else if (tcp_try_rmem_schedule(sk, skb, skb->truesize))
+ else if (tcp_try_rmem_schedule(sk, skb, skb->truesize)) {
+ NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPRCVQDROP);
goto drop;
+ }
eaten = tcp_queue_rcv(sk, skb, 0, &fragstolen);
tcp_rcv_nxt_update(tp, TCP_SKB_CB(skb)->end_seq);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 0/6] Netfilter fixes for net
From: David Miller @ 2018-06-28 4:33 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <20180627152223.3633-1-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Wed, 27 Jun 2018 17:22:17 +0200
> The following patchset contains Netfilter fixes for your net tree:
>
> 1) Missing netlink attribute validation in nf_queue, uncovered by KASAN,
> from Eric Dumazet.
>
> 2) Use pointer to sysctl table, save us 192 bytes of memory per netns.
> Also from Eric.
>
> 3) Possible use-after-free when removing conntrack helper modules due
> to missing synchronize RCU call. From Taehee Yoo.
>
> 4) Fix corner case in systcl writes to nf_log that lead to appending
> data to uninitialized buffer, from Jann Horn.
>
> 5) Jann Horn says we may indefinitely block other users of nf_log_mutex
> if a userspace access in proc_dostring() blocked e.g. due to a
> userfaultfd.
>
> 6) Fix garbage collection race for unconfirmed conntrack entries,
> from Florian Westphal.
>
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git
Pulled, thank you.
^ permalink raw reply
* Re: [PATCH] hinic: reset irq affinity before freeing irq
From: David Miller @ 2018-06-28 4:35 UTC (permalink / raw)
To: weiyongjun1; +Cc: aviad.krawczyk, netdev
In-Reply-To: <1530092857-73580-1-git-send-email-weiyongjun1@huawei.com>
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Wed, 27 Jun 2018 17:47:37 +0800
> Following warning is seen when rmmod hinic. This is because affinity
> value is not reset before calling free_irq(). This patch fixes it.
>
> [ 55.181232] WARNING: CPU: 38 PID: 19589 at kernel/irq/manage.c:1608
> __free_irq+0x2aa/0x2c0
>
> Fixes: 352f58b0d9f2 ("net-next/hinic: Set Rxq irq to specific cpu for NUMA")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [RESEND PATCH] bpfilter: check compiler capability in Kconfig
From: David Miller @ 2018-06-28 4:37 UTC (permalink / raw)
To: yamada.masahiro
Cc: netdev, alexei.starovoitov, mcroce, arnd, linux-kbuild, ast,
linux-kernel, michal.lkml, daniel
In-Reply-To: <1529985336-27522-1-git-send-email-yamada.masahiro@socionext.com>
From: Masahiro Yamada <yamada.masahiro@socionext.com>
Date: Tue, 26 Jun 2018 12:55:35 +0900
> With the brand-new syntax extension of Kconfig, we can directly
> check the compiler capability in the configuration phase.
>
> If the cc-can-link.sh fails, the BPFILTER_UMH is automatically
> hidden by the dependency.
>
> I also deleted 'default n', which is no-op.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next v2] net: vhost: improve performance when enable busyloop
From: Jason Wang @ 2018-06-28 4:40 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: xiangxia.m.yue, virtualization, netdev, Tonghao Zhang
In-Reply-To: <20180627185543-mutt-send-email-mst@kernel.org>
On 2018年06月27日 23:58, Michael S. Tsirkin wrote:
> On Wed, Jun 27, 2018 at 10:24:43PM +0800, Jason Wang wrote:
>>
>> On 2018年06月26日 13:17, xiangxia.m.yue@gmail.com wrote:
>>> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>>>
>>> This patch improves the guest receive performance from
>>> host. On the handle_tx side, we poll the sock receive
>>> queue at the same time. handle_rx do that in the same way.
>>>
>>> For avoiding deadlock, change the code to lock the vq one
>>> by one and use the VHOST_NET_VQ_XX as a subclass for
>>> mutex_lock_nested. With the patch, qemu can set differently
>>> the busyloop_timeout for rx or tx queue.
>>>
>>> We set the poll-us=100us and use the iperf3 to test
>>> its throughput. The iperf3 command is shown as below.
>>>
>>> on the guest:
>>> iperf3 -s -D
>>>
>>> on the host:
>>> iperf3 -c 192.168.1.100 -i 1 -P 10 -t 10 -M 1400
>>>
>>> * With the patch: 23.1 Gbits/sec
>>> * Without the patch: 12.7 Gbits/sec
>>>
>>> Signed-off-by: Tonghao Zhang <zhangtonghao@didichuxing.com>
>> Thanks a lot for the patch. Looks good generally, but please split this big
>> patch into separate ones like:
>>
>> patch 1: lock vqs one by one
>> patch 2: replace magic number of lock annotation
>> patch 3: factor out generic busy polling logic to vhost_net_busy_poll()
>> patch 4: add rx busy polling in tx path.
>>
>> And please cc Michael in v3.
>>
>> Thanks
> Pls include host CPU utilization numbers. You can get them e.g. using
> vmstat. I suspect we also want the polling controllable e.g. through
> an ioctl.
>
I believe we had an ioctl for setting timeout? Or you want another kind
of controlling.
Thanks
^ permalink raw reply
* Re: [patch net-next v2 0/9] net: sched: introduce chain templates support with offloading to mlxsw
From: David Miller @ 2018-06-28 4:48 UTC (permalink / raw)
To: jiri
Cc: netdev, jhs, xiyou.wangcong, jakub.kicinski, simon.horman,
john.hurley, dsahern, mlxsw
In-Reply-To: <20180626080000.12964-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 26 Jun 2018 09:59:51 +0200
> For the TC clsact offload these days, some of HW drivers need
> to hold a magic ball. The reason is, with the first inserted rule inside
> HW they need to guess what fields will be used for the matching. If
> later on this guess proves to be wrong and user adds a filter with a
> different field to match, there's a problem. Mlxsw resolves it now with
> couple of patterns. Those try to cover as many match fields as possible.
> This aproach is far from optimal, both performance-wise and scale-wise.
> Also, there is a combination of filters that in certain order won't
> succeed.
>
> Most of the time, when user inserts filters in chain, he knows right away
> how the filters are going to look like - what type and option will they
> have. For example, he knows that he will only insert filters of type
> flower matching destination IP address. He can specify a template that
> would cover all the filters in the chain.
>
> This patchset is providing the possibility to user to provide such
> template to kernel and propagate it all the way down to device
> drivers.
This series doesn't apply cleanly to net-next, and also there seems to still
be some discussion about how the iproute2 command line should look.
Thanks.
^ permalink raw reply
* Re: [PATCH net] net: macb: initialize bp->queues[0].bp for at91rm9200
From: David Miller @ 2018-06-28 4:50 UTC (permalink / raw)
To: alexandre.belloni; +Cc: rafalo, nicolas.ferre, netdev, linux-kernel
In-Reply-To: <20180626084401.16780-1-alexandre.belloni@bootlin.com>
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
Date: Tue, 26 Jun 2018 10:44:01 +0200
> The macb driver currently crashes on at91rm9200 with the following trace:
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000014
> [...]
> [<c031da44>] (macb_rx_desc) from [<c031f2bc>] (at91ether_open+0x2e8/0x3f8)
> [<c031f2bc>] (at91ether_open) from [<c041e8d8>] (__dev_open+0x120/0x13c)
> [<c041e8d8>] (__dev_open) from [<c041ec08>] (__dev_change_flags+0x17c/0x1a8)
> [<c041ec08>] (__dev_change_flags) from [<c041ec4c>] (dev_change_flags+0x18/0x4c)
> [<c041ec4c>] (dev_change_flags) from [<c07a5f4c>] (ip_auto_config+0x220/0x10b0)
> [<c07a5f4c>] (ip_auto_config) from [<c000a4fc>] (do_one_initcall+0x78/0x18c)
> [<c000a4fc>] (do_one_initcall) from [<c0783e50>] (kernel_init_freeable+0x184/0x1c4)
> [<c0783e50>] (kernel_init_freeable) from [<c0574d70>] (kernel_init+0x8/0xe8)
> [<c0574d70>] (kernel_init) from [<c00090e0>] (ret_from_fork+0x14/0x34)
>
> Solve that by initializing bp->queues[0].bp in at91ether_init (as is done
> in macb_init).
>
> Fixes: ae1f2a56d273 ("net: macb: Added support for many RX queues")
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: Add flag tc_flower_initialized
From: David Miller @ 2018-06-28 4:51 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, leedom
In-Reply-To: <1530004728-18913-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Tue, 26 Jun 2018 14:48:48 +0530
> From: Casey Leedom <leedom@chelsio.com>
>
> Add flag tc_flower_initialized to indicate the
> completion if tc flower initialization.
>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: Add new T5 PCI device id 0x50ae
From: David Miller @ 2018-06-28 4:51 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil
In-Reply-To: <1530004873-19098-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Tue, 26 Jun 2018 14:51:13 +0530
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] net: mscc: ocelot: add more features
From: David Miller @ 2018-06-28 5:19 UTC (permalink / raw)
To: alexandre.belloni
Cc: Allan.Nielsen, razvan.stefanescu, po.liu, thomas.petazzoni,
andrew, f.fainelli, netdev, linux-kernel
In-Reply-To: <20180626122849.13174-1-alexandre.belloni@bootlin.com>
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
Date: Tue, 26 Jun 2018 14:28:47 +0200
> Hi,
>
> This series adds link aggregation and VLAN filtering hardware offload
> support to the ocelot driver.
>
> PTP support will be sent later.
>
> changes in v2:
> - rebased on v4.18-rc1
> - check for aggregation type and only offload it when type is hash (balance-xor
> or 802.3ad)
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next 1/1] tc-tests: add an extreme-case csum action test
From: David Miller @ 2018-06-28 5:24 UTC (permalink / raw)
To: kleib; +Cc: netdev, jhs, xiyou.wangcong, jiri, lucasb
In-Reply-To: <1530022588-27685-1-git-send-email-kleib@mojatatu.com>
From: Keara Leibovitz <kleib@mojatatu.com>
Date: Tue, 26 Jun 2018 10:16:28 -0400
> Added an extreme-case test for all 7 csum action headers.
>
> Signed-off-by: Keara Leibovitz <kleib@mojatatu.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH 0/3] xdp: don't mix XDP_TX and XDP_REDIRECT flush ops
From: David Miller @ 2018-06-28 5:29 UTC (permalink / raw)
To: brouer
Cc: netdev, john.fastabend, jasowang, borkmann, bjorn.topel,
alexei.starovoitov
In-Reply-To: <153002741940.15389.10466368482771753300.stgit@firesoul>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Tue, 26 Jun 2018 17:39:43 +0200
> Fix driver logic that are combining XDP_TX flush and XDP_REDIRECT map
> flushing. These are two different XDP xmit modes, and it is clearly
> wrong to invoke both types of flush operations when only one of the
> XDP xmit modes is used.
Series applied and queued up for -stable, thanks Jesper.
^ permalink raw reply
* Re: [PATCH] bpfilter: fix user mode helper cross compilation
From: Andrew Morton @ 2018-06-28 6:17 UTC (permalink / raw)
To: Matteo Croce; +Cc: netdev
In-Reply-To: <20180620140434.18139-1-mcroce@redhat.com>
On Wed, 20 Jun 2018 16:04:34 +0200 Matteo Croce <mcroce@redhat.com> wrote:
> Use $(OBJDUMP) instead of literal 'objdump' to avoid
> using host toolchain when cross compiling.
>
I'm still having issues here, with ld.
x86_64 machine, ARCH=i386:
y:/usr/src/25> make V=1 M=net/bpfilter
test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( \
echo >&2; \
echo >&2 " ERROR: Kernel configuration is invalid."; \
echo >&2 " include/generated/autoconf.h or include/config/auto.conf are missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it."; \
echo >&2 ; \
/bin/false)
mkdir -p net/bpfilter/.tmp_versions ; rm -f net/bpfilter/.tmp_versions/*
make -f ./scripts/Makefile.build obj=net/bpfilter
(cat /dev/null; echo kernel/net/bpfilter/bpfilter.ko;) > net/bpfilter/modules.order
ld -m elf_i386 -r -o net/bpfilter/bpfilter.o net/bpfilter/bpfilter_kern.o net/bpfilter/bpfilter_umh.o ; scripts/mod/modpost net/bpfilter/bpfilter.o
ld: i386:x86-64 architecture of input file `net/bpfilter/bpfilter_umh.o' is incompatible with i386 output
scripts/Makefile.build:530: recipe for target 'net/bpfilter/bpfilter.o' failed
make[1]: *** [net/bpfilter/bpfilter.o] Error 1
Makefile:1518: recipe for target '_module_net/bpfilter' failed
make: *** [_module_net/bpfilter] Error 2
y:/usr/src/25> ld --version
GNU ld (GNU Binutils for Ubuntu) 2.29.1
^ permalink raw reply
* Re: [patch net-next 0/9] net: sched: introduce chain templates support with offloading to mlxsw
From: Jiri Pirko @ 2018-06-28 6:15 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Linux Netdev List, David Miller, Jamal Hadi Salim, Cong Wang,
Simon Horman, John Hurley, David Ahern, mlxsw
In-Reply-To: <20180627113624.5f8d74e9@cakuba.netronome.com>
Wed, Jun 27, 2018 at 08:36:24PM CEST, jakub.kicinski@netronome.com wrote:
>On Wed, 27 Jun 2018 09:50:17 +0200, Jiri Pirko wrote:
>> Tue, Jun 26, 2018 at 11:18:58PM CEST, jakub.kicinski@netronome.com wrote:
>> >On Tue, 26 Jun 2018 09:12:17 +0200, Jiri Pirko wrote:
>> >> Tue, Jun 26, 2018 at 09:00:45AM CEST, jakub.kicinski@netronome.com wrote:
>> >> >On Mon, Jun 25, 2018 at 11:43 PM, Jiri Pirko <jiri@resnulli.us> wrote:
>> >> >> Tue, Jun 26, 2018 at 06:58:50AM CEST, jakub.kicinski@netronome.com wrote:
>> >> >>>On Mon, 25 Jun 2018 23:01:39 +0200, Jiri Pirko wrote:
>> >> >>>> From: Jiri Pirko <jiri@mellanox.com>
>> >> >>>>
>> >> >>>> For the TC clsact offload these days, some of HW drivers need
>> >> >>>> to hold a magic ball. The reason is, with the first inserted rule inside
>> >> >>>> HW they need to guess what fields will be used for the matching. If
>> >> >>>> later on this guess proves to be wrong and user adds a filter with a
>> >> >>>> different field to match, there's a problem. Mlxsw resolves it now with
>> >> >>>> couple of patterns. Those try to cover as many match fields as possible.
>> >> >>>> This aproach is far from optimal, both performance-wise and scale-wise.
>> >> >>>> Also, there is a combination of filters that in certain order won't
>> >> >>>> succeed.
>> >> >>>>
>> >> >>>> Most of the time, when user inserts filters in chain, he knows right away
>> >> >>>> how the filters are going to look like - what type and option will they
>> >> >>>> have. For example, he knows that he will only insert filters of type
>> >> >>>> flower matching destination IP address. He can specify a template that
>> >> >>>> would cover all the filters in the chain.
>> >> >>>
>> >> >>>Perhaps it's lack of sleep, but this paragraph threw me a little off
>> >> >>>the track. IIUC the goal of this set is to provide a way to inform the
>> >> >>>HW about expected matches before any rule is programmed into the HW.
>> >> >>>Not before any rule is added to a particular chain. One can just use
>> >> >>>the first rule in the chain to make a guess about the chain, but thanks
>> >> >>>to this set user can configure *all* chains before any rules are added.
>> >> >>
>> >> >> The template is per-chain. User can use template for chain x and
>> >> >> not-use it for chain y. Up to him.
>> >> >
>> >> >Makes sense.
>> >> >
>> >> >I can't help but wonder if it'd be better to associate the
>> >> >constraints/rules with chains instead of creating a new "template"
>> >> >object. It seems more natural to create a chain with specific
>> >> >constraints in place than add and delete template of which there can
>> >> >be at most one to a chain... Perhaps that's more about the user space
>> >> >tc command line. Anyway, not a strong objection, just a thought.
>> >>
>> >> Hmm. I don't think it is good idea. User should see the template in a
>> >> "show" command per chain. We would have to have 2 show commands, one to
>> >> list the template objects and one to list templates per chains. It makes
>> >> things more complicated for no good reason. I think that this simple
>> >> chain-lock is easier and serves the purpose.
>> >
>> >Hm, I think the dump is fine, what I was thinking about was:
>> >
>> ># tc chain add dev dummy0 ingress chain_index 22 \
>> > ^^^^^
>> > template proto ip \
>> > ^^^^^^^^
>> > flower dst_mac 00:00:00:00:00:00/00:00:00:00:FF:FF
>>
>> Okay, I got it. I see 2 issues.
>> 1) user might expect to add a chain without the template. But that does
>> not make sense really. Chains are created/deleted implicitly
>> according to refcount.
>> 2) there is not chain object like this available to user. Adding it just
>> for template looks odd. Also, the "filter" and "template" are very
>> much alike. They both are added to a chain, they both implicitly
>> create chain if it does not exist, etc.
>
>Yeah, that part makes is tricky :/
>
>> if you don't like "tc filter template add dev dummy0 ingress", how
>> about:
>> "tc template add dev dummy0 ingress ..."
>> "tc template add dev dummy0 ingress chain 22 ..."
>> that makes more sense I think.
>
>Mmm.. how about:
>
> tc chaintemplate add dev dummy0 ingress...
This looks fine to me.
>
>or
>
> tc restrictedchain add dev dummy0 ingress chain_index XX template ...
^ permalink raw reply
* Re: [patch net-next 0/9] net: sched: introduce chain templates support with offloading to mlxsw
From: Jiri Pirko @ 2018-06-28 6:18 UTC (permalink / raw)
To: Cong Wang
Cc: sridhar.samudrala, Jakub Kicinski,
Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
Simon Horman, john.hurley, David Ahern, mlxsw
In-Reply-To: <CAM_iQpUiod0iG=h8STfkKEPQoJUe==B0Q3oPj3kR5Wy7+5FBqA@mail.gmail.com>
Wed, Jun 27, 2018 at 07:04:32PM CEST, xiyou.wangcong@gmail.com wrote:
>On Wed, Jun 27, 2018 at 9:46 AM Samudrala, Sridhar
><sridhar.samudrala@intel.com> wrote:
>>
>> On 6/27/2018 12:50 AM, Jiri Pirko wrote:
>> > if you don't like "tc filter template add dev dummy0 ingress", how
>> > about:
>> > "tc template add dev dummy0 ingress ..."
>> > "tc template add dev dummy0 ingress chain 22 ..."
>> > that makes more sense I think.
>
>Better than 'tc filter template', but this doesn't reflect 'template'
>is a template of tc filter, it could be an action etc., since it is in the
It's a template of filter per chain. I don't understand how it could be
an action...
>same position with 'tc action/filter/qdisc'.
>
>
>>
>> Isn't it possible to avoid introducing another keyword 'template',
>>
>> Can't we just do
>> tc chain add dev dummy0 ingress flower chain_index 0
>> to create a chain that takes any types of flower rules with index 0
>> and
>> tc chain add dev dummy0 ingress flower chain_index 22
>> dst_mac 00:00:00:00:00:00/00:00:00:00:FF:FF
>> tc chain add dev dummy0 ingress flower chain_index 23
>> dst_ip 192.168.0.0/16
>> to create 2 chains 22 and 23 that allow rules with specific fields.
>
>Sounds good too. Since filter chain can be shared by qdiscs,
>a 'tc chain' sub-command makes sense, and would probably make
>it easier to be shared.
We don't have such specific object. It is implicit. We create it
whenever someone users it. Either filter of chain. I don't like new "tc
chain" object in cmdline. It really isn't.
^ permalink raw reply
* Re: [patch net-next v2 0/9] net: sched: introduce chain templates support with offloading to mlxsw
From: Jiri Pirko @ 2018-06-28 6:25 UTC (permalink / raw)
To: David Miller
Cc: netdev, jhs, xiyou.wangcong, jakub.kicinski, simon.horman,
john.hurley, dsahern, mlxsw
In-Reply-To: <20180628.134826.1129904828597717313.davem@davemloft.net>
Thu, Jun 28, 2018 at 06:48:26AM CEST, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.us>
>Date: Tue, 26 Jun 2018 09:59:51 +0200
>
>> For the TC clsact offload these days, some of HW drivers need
>> to hold a magic ball. The reason is, with the first inserted rule inside
>> HW they need to guess what fields will be used for the matching. If
>> later on this guess proves to be wrong and user adds a filter with a
>> different field to match, there's a problem. Mlxsw resolves it now with
>> couple of patterns. Those try to cover as many match fields as possible.
>> This aproach is far from optimal, both performance-wise and scale-wise.
>> Also, there is a combination of filters that in certain order won't
>> succeed.
>>
>> Most of the time, when user inserts filters in chain, he knows right away
>> how the filters are going to look like - what type and option will they
>> have. For example, he knows that he will only insert filters of type
>> flower matching destination IP address. He can specify a template that
>> would cover all the filters in the chain.
>>
>> This patchset is providing the possibility to user to provide such
>> template to kernel and propagate it all the way down to device
>> drivers.
>
>This series doesn't apply cleanly to net-next, and also there seems to still
>be some discussion about how the iproute2 command line should look.
Will re-spin. Thanks.
>
>Thanks.
^ permalink raw reply
* Re: [PATCH net-next 3/5] sctp: add spp_ipv6_flowlabel and spp_dscp for sctp_paddrparams
From: Xin Long @ 2018-06-28 6:40 UTC (permalink / raw)
To: 吉藤英明
Cc: Marcelo Ricardo Leitner, Neil Horman, David Miller, network dev,
linux-sctp, yoshfuji
In-Reply-To: <CAPA1RqDprqydZ5YpODEa-aLX2seL1tGB+cCc02HX+O89f7zczw@mail.gmail.com>
On Tue, Jun 26, 2018 at 8:02 PM, 吉藤英明
<hideaki.yoshifuji@miraclelinux.com> wrote:
> 2018-06-26 13:33 GMT+09:00 Xin Long <lucien.xin@gmail.com>:
>> On Tue, Jun 26, 2018 at 12:31 AM, Marcelo Ricardo Leitner
>> <marcelo.leitner@gmail.com> wrote:
>>> Hi,
>>>
>>> On Tue, Jun 26, 2018 at 01:12:00AM +0900, 吉藤英明 wrote:
>>>> Hi,
>>>>
>>>> 2018-06-25 22:03 GMT+09:00 Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>:
>>>> > On Mon, Jun 25, 2018 at 07:28:47AM -0400, Neil Horman wrote:
>>>> >> On Mon, Jun 25, 2018 at 04:31:26PM +0900, David Miller wrote:
>>>> >> > From: Xin Long <lucien.xin@gmail.com>
>>>> >> > Date: Mon, 25 Jun 2018 10:14:35 +0800
>>>> >> >
>>>> >> > > struct sctp_paddrparams {
>>>> >> > > @@ -773,6 +775,8 @@ struct sctp_paddrparams {
>>>> >> > > __u32 spp_pathmtu;
>>>> >> > > __u32 spp_sackdelay;
>>>> >> > > __u32 spp_flags;
>>>> >> > > + __u32 spp_ipv6_flowlabel;
>>>> >> > > + __u8 spp_dscp;
>>>> >> > > } __attribute__((packed, aligned(4)));
>>>> >> >
>>>> >> > I don't think you can change the size of this structure like this.
>>>> >> >
>>>> >> > This check in sctp_setsockopt_peer_addr_params():
>>>> >> >
>>>> >> > if (optlen != sizeof(struct sctp_paddrparams))
>>>> >> > return -EINVAL;
>>>> >> >
>>>> >> > is going to trigger in old kernels when executing programs
>>>> >> > built against the new struct definition.
>>>> >
>>>> > That will happen, yes, but do we really care about being future-proof
>>>> > here? I mean: if we also update such check(s) to support dealing with
>>>> > smaller-than-supported structs, newer kernels will be able to run
>>>> > programs built against the old struct, and the new one; while building
>>>> > using newer headers and running on older kernel may fool the
>>>> > application in other ways too (like enabling support for something
>>>> > that is available on newer kernel and that is not present in the older
>>>> > one).
>>>>
>>>> We should not break existing apps.
>>>> We still accept apps of pre-2.4 era without sin6_scope_id
>>>> (e.g., net/ipv6/af_inet6.c:inet6_bind()).
>>>
>>> Yes. That's what I tried to say. That is supporting an old app built
>>> with old kernel headers and running on a newer kernel, and not the
>>> other way around (an app built with fresh headers and running on an
>>> old kernel).
>> To make it, I will update the check like:
>>
>> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
>> index 1df5d07..c949d8c 100644
>> --- a/net/sctp/socket.c
>> +++ b/net/sctp/socket.c
>> @@ -2715,13 +2715,18 @@ static int
>> sctp_setsockopt_peer_addr_params(struct sock *sk,
>> struct sctp_sock *sp = sctp_sk(sk);
>> int error;
>> int hb_change, pmtud_change, sackdelay_change;
>> + int plen = sizeof(params);
>> + int old_plen = plen - sizeof(u32) * 2;
>
> if (optlen < offsetof(struct sctp_paddrparams, spp_ipv6_flowlabel))
> maybe?
Hi, yoshfuji,
offsetof() is better. thank you.
>
>>
>> - if (optlen != sizeof(struct sctp_paddrparams))
>> + if (optlen != plen && optlen != old_plen)
>> return -EINVAL;
>>
>> if (copy_from_user(¶ms, optval, optlen))
>> return -EFAULT;
>>
>> + if (optlen == old_plen)
>> + params.spp_flags &= ~(SPP_DSCP | SPP_IPV6_FLOWLABEL);
>
> I think we should return -EINVAL if size is not new one.
Sorry, if we returned -EINVAL when size is the old one,
how can we guarantee an old app built with old kernel
headers and running on a newer kernel works well?
or you meant?
if ((params.spp_flags & (SPP_DSCP | SPP_IPV6_FLOWLABEL)) &&
optlen != plen)
return EINVAL;
>
> --yoshfuji
>
>> +
>> /* Validate flags and value parameters. */
>> hb_change = params.spp_flags & SPP_HB;
>> pmtud_change = params.spp_flags & SPP_PMTUD;
>> @@ -5591,10 +5596,13 @@ static int
>> sctp_getsockopt_peer_addr_params(struct sock *sk, int len,
>> struct sctp_transport *trans = NULL;
>> struct sctp_association *asoc = NULL;
>> struct sctp_sock *sp = sctp_sk(sk);
>> + int plen = sizeof(params);
>> + int old_plen = plen - sizeof(u32) * 2;
>>
>> - if (len < sizeof(struct sctp_paddrparams))
>> + if (len < old_plen)
>> return -EINVAL;
>> - len = sizeof(struct sctp_paddrparams);
>> +
>> + len = len >= plen ? plen : old_plen;
>> if (copy_from_user(¶ms, optval, len))
>> return -EFAULT;
>>
>> does it look ok to you?
^ permalink raw reply
* Re: [PATCH net-next v2] net: vhost: improve performance when enable busyloop
From: Tonghao Zhang @ 2018-06-28 6:42 UTC (permalink / raw)
To: jasowang
Cc: Linux Kernel Network Developers, Tonghao Zhang, mst,
virtualization
In-Reply-To: <369bea44-6ebd-337a-b20b-a28a604fa2e9@redhat.com>
On Wed, Jun 27, 2018 at 10:24 PM Jason Wang <jasowang@redhat.com> wrote:
>
>
>
> On 2018年06月26日 13:17, xiangxia.m.yue@gmail.com wrote:
> > From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> >
> > This patch improves the guest receive performance from
> > host. On the handle_tx side, we poll the sock receive
> > queue at the same time. handle_rx do that in the same way.
> >
> > For avoiding deadlock, change the code to lock the vq one
> > by one and use the VHOST_NET_VQ_XX as a subclass for
> > mutex_lock_nested. With the patch, qemu can set differently
> > the busyloop_timeout for rx or tx queue.
> >
> > We set the poll-us=100us and use the iperf3 to test
> > its throughput. The iperf3 command is shown as below.
> >
> > on the guest:
> > iperf3 -s -D
> >
> > on the host:
> > iperf3 -c 192.168.1.100 -i 1 -P 10 -t 10 -M 1400
> >
> > * With the patch: 23.1 Gbits/sec
> > * Without the patch: 12.7 Gbits/sec
> >
> > Signed-off-by: Tonghao Zhang <zhangtonghao@didichuxing.com>
>
> Thanks a lot for the patch. Looks good generally, but please split this
> big patch into separate ones like:
>
> patch 1: lock vqs one by one
> patch 2: replace magic number of lock annotation
> patch 3: factor out generic busy polling logic to vhost_net_busy_poll()
> patch 4: add rx busy polling in tx path.
>
> And please cc Michael in v3.
Thanks. will be done.
> Thanks
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH net-next v2] net: vhost: improve performance when enable busyloop
From: Tonghao Zhang @ 2018-06-28 6:44 UTC (permalink / raw)
To: mst
Cc: jasowang, virtualization, Linux Kernel Network Developers,
Tonghao Zhang
In-Reply-To: <20180627185543-mutt-send-email-mst@kernel.org>
On Wed, Jun 27, 2018 at 11:58 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Wed, Jun 27, 2018 at 10:24:43PM +0800, Jason Wang wrote:
> >
> >
> > On 2018年06月26日 13:17, xiangxia.m.yue@gmail.com wrote:
> > > From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> > >
> > > This patch improves the guest receive performance from
> > > host. On the handle_tx side, we poll the sock receive
> > > queue at the same time. handle_rx do that in the same way.
> > >
> > > For avoiding deadlock, change the code to lock the vq one
> > > by one and use the VHOST_NET_VQ_XX as a subclass for
> > > mutex_lock_nested. With the patch, qemu can set differently
> > > the busyloop_timeout for rx or tx queue.
> > >
> > > We set the poll-us=100us and use the iperf3 to test
> > > its throughput. The iperf3 command is shown as below.
> > >
> > > on the guest:
> > > iperf3 -s -D
> > >
> > > on the host:
> > > iperf3 -c 192.168.1.100 -i 1 -P 10 -t 10 -M 1400
> > >
> > > * With the patch: 23.1 Gbits/sec
> > > * Without the patch: 12.7 Gbits/sec
> > >
> > > Signed-off-by: Tonghao Zhang <zhangtonghao@didichuxing.com>
> >
> > Thanks a lot for the patch. Looks good generally, but please split this big
> > patch into separate ones like:
> >
> > patch 1: lock vqs one by one
> > patch 2: replace magic number of lock annotation
> > patch 3: factor out generic busy polling logic to vhost_net_busy_poll()
> > patch 4: add rx busy polling in tx path.
> >
> > And please cc Michael in v3.
> >
> > Thanks
>
> Pls include host CPU utilization numbers. You can get them e.g. using
> vmstat.
OK, thanks.
> I suspect we also want the polling controllable e.g. through
> an ioctl.
>
> --
> MST
^ permalink raw reply
* Re: [PATCH net-next] sh_eth: fix *enum* {A|M}PR_BIT
From: David Miller @ 2018-06-28 7:02 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, linux-renesas-soc
In-Reply-To: <e67e6256-4ae9-4527-d482-cf3bb50921cf@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Tue, 26 Jun 2018 18:42:33 +0300
> The *enum* {A|M}PR_BIT were declared in the commit 86a74ff21a7a ("net:
> sh_eth: add support for Renesas SuperH Ethernet") adding SH771x support,
> however the SH771x manual doesn't have the APR/MPR registers described
> and the code writing to them for SH7710 was later removed by the commit
> 380af9e390ec ("net: sh_eth: CPU dependency code collect to "struct
> sh_eth_cpu_data""). All the newer SoC manuals have these registers
> documented as having a 16-bit TIME parameter of the PAUSE frame, not
> 1-bit -- update the *enum* accordingly, fixing up the APR/MPR writes...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] tcp: remove one indentation level in tcp_create_openreq_child
From: David Miller @ 2018-06-28 7:03 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet
In-Reply-To: <20180626154549.102366-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Tue, 26 Jun 2018 08:45:49 -0700
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH v5 net-next] net:sched: add action inheritdsfield to skbedit
From: David Miller @ 2018-06-28 7:05 UTC (permalink / raw)
To: qiaobinf; +Cc: marcelo.leitner, dcaratti, michel, netdev, jhs, xiyou.wangcong
In-Reply-To: <8F70554D-4080-4064-8130-A0089BB828A2@bu.edu>
From: "Fu, Qiaobin" <qiaobinf@bu.edu>
Date: Tue, 26 Jun 2018 15:58:35 +0000
> diff --git a/include/uapi/linux/tc_act/tc_skbedit.h b/include/uapi/linux/tc_act/tc_skbedit.h
> index fbcfe27a4e6c..6de6071ebed6 100644
> --- a/include/uapi/linux/tc_act/tc_skbedit.h
> +++ b/include/uapi/linux/tc_act/tc_skbedit.h
> @@ -30,6 +30,7 @@
> #define SKBEDIT_F_MARK 0x4
> #define SKBEDIT_F_PTYPE 0x8
> #define SKBEDIT_F_MASK 0x10
> +#define SKBEDIT_F_INHERITDSFIELD 0x20
This patch is heavily corrupted by your email client.
Please fix this, email a test patch to yourself, and do not resubmit
this patch to the list until you can successfully apply the patch
in that test email.
^ permalink raw reply
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