* [PATCH v5 net-next 0/3] rds: IPv6 support
From: Ka-Cheong Poon @ 2018-07-24 3:51 UTC (permalink / raw)
To: netdev; +Cc: santosh.shilimkar, davem, rds-devel, sowmini.varadhan
This patch set adds IPv6 support to the kernel RDS and related
modules. Existing RDS apps using IPv4 address continue to run without
any problem. New RDS apps which want to use IPv6 address can do so by
passing the address in struct sockaddr_in6 to bind(), connect() or
sendmsg(). And those apps also need to use the new IPv6 equivalents
of some of the existing socket options as the existing options use a
32 bit integer to store IP address.
All RDS code now use struct in6_addr to store IP address. IPv4
address is stored as an IPv4 mapped address.
Header file changes
There are many data structures (RDS socket options) used by RDS apps
which use a 32 bit integer to store IP address. To support IPv6,
struct in6_addr needs to be used. To ensure backward compatibility, a
new data structure is introduced for each of those data structures
which use a 32 bit integer to represent an IP address. And new socket
options are introduced to use those new structures. This means that
existing apps should work without a problem with the new RDS module.
For apps which want to use IPv6, those new data structures and socket
options can be used. IPv4 mapped address is used to represent IPv4
address in the new data structures.
Internally, all RDS data structures which contain an IP address are
changed to use struct in6_addr to store the address. IPv4 address is
stored as an IPv4 mapped address. All the functions which take an IP
address as argument are also changed to use struct in6_addr.
RDS/RDMA/IB uses a private data (struct rds_ib_connect_private)
exchange between endpoints at RDS connection establishment time to
support RDMA. This private data exchange uses a 32 bit integer to
represent an IP address. This needs to be changed in order to support
IPv6. A new private data struct rds6_ib_connect_private is introduced
to handle this. To ensure backward compatibility, an IPv6 capable RDS
stack uses another RDMA listener port (RDS_CM_PORT) to accept IPv6
connection. And it continues to use the original RDS_PORT for IPv4 RDS
connections. When it needs to communicate with an IPv6 peer, it uses
the RDS_TCP_PORT to send the connection set up request.
RDS/TCP changes
TCP related code is changed to support IPv6. Note that only an IPv6
TCP listener on port RDS_TCP_PORT is created as it can accept both
IPv4 and IPv6 connection requests.
IB/RDMA changes
The initial private data exchange between IB endpoints using RDMA is
changed to support IPv6 address instead, if the peer address is IPv6.
To ensure backward compatibility, annother RDMA listener port
(RDS_CM_PORT) is used to accept IPv6 connection. An IPv6 capable RDS
module continues to use the original RDS_PORT for IPv4 RDS
connections. When it needs to communicate with an IPv6 peer, it uses
the RDS_CM_PORT to send the connection set up request.
Ka-Cheong Poon (3):
rds: Changing IP address internal representation to struct in6_addr
rds: Enable RDS IPv6 support
rds: Extend RDS API for IPv6 support
include/uapi/linux/rds.h | 69 ++++++++++-
net/rds/af_rds.c | 201 ++++++++++++++++++++++++------
net/rds/bind.c | 136 ++++++++++++++++-----
net/rds/cong.c | 23 ++--
net/rds/connection.c | 259 ++++++++++++++++++++++++++++++---------
net/rds/ib.c | 114 +++++++++++++++--
net/rds/ib.h | 51 ++++++--
net/rds/ib_cm.c | 309 +++++++++++++++++++++++++++++++++++------------
net/rds/ib_mr.h | 2 +
net/rds/ib_rdma.c | 24 ++--
net/rds/ib_recv.c | 18 +--
net/rds/ib_send.c | 10 +-
net/rds/loop.c | 7 +-
net/rds/rdma.c | 6 +-
net/rds/rdma_transport.c | 84 ++++++++++---
net/rds/rdma_transport.h | 5 +
net/rds/rds.h | 88 +++++++++-----
net/rds/recv.c | 76 +++++++++---
net/rds/send.c | 114 ++++++++++++++---
net/rds/tcp.c | 128 ++++++++++++++++----
net/rds/tcp.h | 2 +-
net/rds/tcp_connect.c | 68 ++++++++---
net/rds/tcp_listen.c | 74 +++++++++---
net/rds/tcp_recv.c | 9 +-
net/rds/tcp_send.c | 4 +-
net/rds/threads.c | 69 +++++++++--
net/rds/transport.c | 15 ++-
27 files changed, 1543 insertions(+), 422 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [patch net-next v4 00/12] sched: introduce chain templates support with offloading to mlxsw
From: David Miller @ 2018-07-24 3:45 UTC (permalink / raw)
To: jiri
Cc: netdev, jhs, xiyou.wangcong, jakub.kicinski, simon.horman,
john.hurley, dsahern, mlxsw, sridhar.samudrala
In-Reply-To: <20180723072312.4153-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Mon, 23 Jul 2018 09:23:03 +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.
Series applied, thanks Jiri!
^ permalink raw reply
* Re: [PATCH v3 bpf-next 6/8] xdp: Add a flag for disabling napi_direct of xdp_return_frame in xdp_mem_info
From: Jakub Kicinski @ 2018-07-24 3:38 UTC (permalink / raw)
To: Toshiaki Makita
Cc: Toshiaki Makita, netdev, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer
In-Reply-To: <bd0c97b3-1abe-960e-bed6-d7706f0d7376@lab.ntt.co.jp>
On Tue, 24 Jul 2018 11:43:11 +0900, Toshiaki Makita wrote:
> On 2018/07/24 10:22, Jakub Kicinski wrote:
> > On Mon, 23 Jul 2018 00:13:06 +0900, Toshiaki Makita wrote:
> >> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> >>
> >> We need some mechanism to disable napi_direct on calling
> >> xdp_return_frame_rx_napi() from some context.
> >> When veth gets support of XDP_REDIRECT, it will redirects packets which
> >> are redirected from other devices. On redirection veth will reuse
> >> xdp_mem_info of the redirection source device to make return_frame work.
> >> But in this case .ndo_xdp_xmit() called from veth redirection uses
> >> xdp_mem_info which is not guarded by NAPI, because the .ndo_xdp_xmit is
> >> not called directly from the rxq which owns the xdp_mem_info.
> >>
> >> This approach introduces a flag in xdp_mem_info to indicate that
> >> napi_direct should be disabled even when _rx_napi variant is used.
> >>
> >> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> >
> > To be clear - you will modify flags of the original source device if it
> > ever redirected a frame to a software device like veth? Seems a bit
> > heavy handed. The xdp_return_frame_rx_napi() is only really used on
> > error paths, but still.. Also as you note the original NAPI can run
> > concurrently with your veth dest one, but also with NAPIs of other veth
> > devices, so the non-atomic xdp.rxq->mem.flags |= XDP_MEM_RF_NO_DIRECT;
> > makes me worried.
>
> xdp_mem_info is copied in xdp_frame in convert_to_xdp_frame() so the
> field is local to the frame. Changing flags affects only the frame.
> xdp.rxq is local to NAPI thread, so no worries about atomicity.
Ah, right! mem_info used to be just 8B, now it would be 12B.
Alternatively we could perhaps add this info to struct redirect_info,
through xdp_do_redirect() to avoid the per-frame cost. I'm not sure
that's better.
> > Would you mind elaborating why not handle the RX completely in the NAPI
> > context of the original device?
>
> Originally it was difficult to implement .ndo_xdp_xmit() and
> .ndo_xdp_flush() model without creating NAPI in veth. Now it is changed
> so I'm not sure how difficult it is at this point.
> But in any case I want to avoid stack inflation by veth NAPI. (Imagine
> some misconfiguration like calling XDP_TX on both side of veth...)
True :/
^ permalink raw reply
* Re: [PATCH] net: axienet: Fix double deregister of mdio
From: Shubhrajyoti Datta @ 2018-07-24 4:42 UTC (permalink / raw)
To: David Miller; +Cc: Shubhrajyoti Datta, netdev, Michal Simek, linux-kernel
In-Reply-To: <20180723.094332.1263746631250670875.davem@davemloft.net>
Hi David,
On Mon, Jul 23, 2018 at 10:13 PM, David Miller <davem@davemloft.net> wrote:
> From: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
> Date: Mon, 23 Jul 2018 14:08:47 +0530
>
>> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c b/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
>> index 16c3bfb..757a3b3 100644
>> --- a/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
>> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
>> @@ -218,6 +218,7 @@ int axienet_mdio_setup(struct axienet_local *lp, struct device_node *np)
>> ret = of_mdiobus_register(bus, np1);
>> if (ret) {
>> mdiobus_free(bus);
>> + lp->mii_bus = NULL;
>> return ret;
>> }
>
> Your patch was corrupted by your email client, in particular it has transformed TAB
> characters into SPACEs.
>
> Please fix this, email the patch to yourself as a test, and please do
> not send the patch here to the list again until you can successfully
> apply the patch you receive in that test email.
>
>> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
>
> This is inappropriate for postings to this mailing list, please disable this footer
> if you would like to post here.
>
> Thank you.
Apologies for the same.
Resent now .
^ permalink raw reply
* Re: [PATCH v4 net-next 2/3] rds: Enable RDS IPv6 support
From: Ka-Cheong Poon @ 2018-07-24 3:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev, santosh.shilimkar, rds-devel, sowmini.varadhan
In-Reply-To: <20180723.202033.1935833384843765067.davem@davemloft.net>
On 07/24/2018 11:20 AM, David Miller wrote:
> From: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
> Date: Tue, 24 Jul 2018 11:18:24 +0800
>
>> On 07/24/2018 02:15 AM, David Miller wrote:
>>> From: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
>>> Date: Mon, 23 Jul 2018 07:16:11 -0700
>>>
>>>> @@ -163,15 +165,29 @@ int rds_tcp_accept_one(struct socket *sock)
>>>> inet = inet_sk(new_sock->sk);
>>>> + my_addr = &new_sock->sk->sk_v6_rcv_saddr;
>>>> + peer_addr = &new_sock->sk->sk_v6_daddr,
>>>> rdsdebug("accepted tcp %pI6c:%u -> %pI6c:%u\n",
>>> Note that comma, instead of a semicolon, at the end of the peer_addr
>>> assignment.
>>> This doesn't even compile.
>>
>>
>> Strange, the compiler did not complain. Will check why's
>> that.
>
> Try allmodconfig
That catches it. Thanks!
--
K. Poon
ka-cheong.poon@oracle.com
^ permalink raw reply
* [PATCH] net: axienet: Fix double deregister of mdio
From: shubhrajyoti.datta @ 2018-07-24 4:39 UTC (permalink / raw)
To: netdev; +Cc: shubhrajyoti.datta, michal.simek, linux-kernel,
Shubhrajyoti Datta
From: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
If the registration fails then mdio_unregister is called.
However at unbind the unregister ia attempted again resulting
in the below crash
[ 73.544038] kernel BUG at drivers/net/phy/mdio_bus.c:415!
[ 73.549362] Internal error: Oops - BUG: 0 [#1] SMP
[ 73.554127] Modules linked in:
[ 73.557168] CPU: 0 PID: 2249 Comm: sh Not tainted 4.14.0 #183
[ 73.562895] Hardware name: xlnx,zynqmp (DT)
[ 73.567062] task: ffffffc879e41180 task.stack: ffffff800cbe0000
[ 73.572973] PC is at mdiobus_unregister+0x84/0x88
[ 73.577656] LR is at axienet_mdio_teardown+0x18/0x30
[ 73.582601] pc : [<ffffff80085fa4cc>] lr : [<ffffff8008616858>]
pstate: 20000145
[ 73.589981] sp : ffffff800cbe3c30
[ 73.593277] x29: ffffff800cbe3c30 x28: ffffffc879e41180
[ 73.598573] x27: ffffff8008a21000 x26: 0000000000000040
[ 73.603868] x25: 0000000000000124 x24: ffffffc879efe920
[ 73.609164] x23: 0000000000000060 x22: ffffffc879e02000
[ 73.614459] x21: ffffffc879e02800 x20: ffffffc87b0b8870
[ 73.619754] x19: ffffffc879e02800 x18: 000000000000025d
[ 73.625050] x17: 0000007f9a719ad0 x16: ffffff8008195bd8
[ 73.630345] x15: 0000007f9a6b3d00 x14: 0000000000000010
[ 73.635640] x13: 74656e7265687465 x12: 0000000000000030
[ 73.640935] x11: 0000000000000030 x10: 0101010101010101
[ 73.646231] x9 : 241f394f42533300 x8 : ffffffc8799f6e98
[ 73.651526] x7 : ffffffc8799f6f18 x6 : ffffffc87b0ba318
[ 73.656822] x5 : ffffffc87b0ba498 x4 : 0000000000000000
[ 73.662117] x3 : 0000000000000000 x2 : 0000000000000008
[ 73.667412] x1 : 0000000000000004 x0 : ffffffc8799f4000
[ 73.672708] Process sh (pid: 2249, stack limit = 0xffffff800cbe0000)
Fix the same by making the bus NULL on unregister.
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
---
drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c b/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
index 16c3bfb..757a3b3 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
@@ -218,6 +218,7 @@ int axienet_mdio_setup(struct axienet_local *lp, struct device_node *np)
ret = of_mdiobus_register(bus, np1);
if (ret) {
mdiobus_free(bus);
+ lp->mii_bus = NULL;
return ret;
}
return 0;
--
2.7.4
^ permalink raw reply related
* Re: pull-request: wireless-drivers-next 2018-07-23
From: David Miller @ 2018-07-24 4:30 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87tvopx3pm.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Mon, 23 Jul 2018 20:27:17 +0300
> this first pull request for 4.19 got delayed as I was on vacation for
> two weeks. I was supposed to send this before my vacation but didn't
> manage to do it due to other urgent stuff, but I'll try to catch up with
> everything this week so that we get everything ready on time for 4.19.
>
> More info in the signed tag below and please let me know if there are
> any problems.
Pulled, thanks Kalle.
^ permalink raw reply
* Re: [pull request][net-next V2 00/12] Mellanox, mlx5e updates 2018-07-18
From: David Miller @ 2018-07-24 3:23 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20180723221129.21625-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Mon, 23 Jul 2018 15:11:17 -0700
> This series includes updates for mlx5e net device driver, with a couple
> of major features and some misc updates.
>
> Please notice the mlx5-next merge patch at the beginning:
> "Merge branch 'mlx5-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux"
>
> For more information please see tag log below.
>
> Please pull and let me know if there's any problem.
>
> v1->v2:
> - Dropped "Support PCIe buffer congestion handling via Devlink" patches until the
> comments are addressed.
Pulled, thanks Saeed.
^ permalink raw reply
* Re: [PATCH v4 net-next 2/3] rds: Enable RDS IPv6 support
From: David Miller @ 2018-07-24 3:20 UTC (permalink / raw)
To: ka-cheong.poon; +Cc: netdev, santosh.shilimkar, rds-devel, sowmini.varadhan
In-Reply-To: <0257db98-60d4-6bca-66b5-c0bd0f63d234@oracle.com>
From: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
Date: Tue, 24 Jul 2018 11:18:24 +0800
> On 07/24/2018 02:15 AM, David Miller wrote:
>> From: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
>> Date: Mon, 23 Jul 2018 07:16:11 -0700
>>
>>> @@ -163,15 +165,29 @@ int rds_tcp_accept_one(struct socket *sock)
>>> inet = inet_sk(new_sock->sk);
>>> + my_addr = &new_sock->sk->sk_v6_rcv_saddr;
>>> + peer_addr = &new_sock->sk->sk_v6_daddr,
>>> rdsdebug("accepted tcp %pI6c:%u -> %pI6c:%u\n",
>> Note that comma, instead of a semicolon, at the end of the peer_addr
>> assignment.
>> This doesn't even compile.
>
>
> Strange, the compiler did not complain. Will check why's
> that.
Try allmodconfig
^ permalink raw reply
* Re: [PATCH v4 net-next 2/3] rds: Enable RDS IPv6 support
From: Ka-Cheong Poon @ 2018-07-24 3:18 UTC (permalink / raw)
To: David Miller; +Cc: netdev, santosh.shilimkar, rds-devel, sowmini.varadhan
In-Reply-To: <20180723.111545.2052989865778508499.davem@davemloft.net>
On 07/24/2018 02:15 AM, David Miller wrote:
> From: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
> Date: Mon, 23 Jul 2018 07:16:11 -0700
>
>> @@ -163,15 +165,29 @@ int rds_tcp_accept_one(struct socket *sock)
>>
>> inet = inet_sk(new_sock->sk);
>>
>> + my_addr = &new_sock->sk->sk_v6_rcv_saddr;
>> + peer_addr = &new_sock->sk->sk_v6_daddr,
>> rdsdebug("accepted tcp %pI6c:%u -> %pI6c:%u\n",
>
> Note that comma, instead of a semicolon, at the end of the peer_addr
> assignment.
>
> This doesn't even compile.
Strange, the compiler did not complain. Will check why's
that.
Thanks.
--
K. Poon
ka-cheong.poon@oracle.com
^ permalink raw reply
* Re: [PATCH] 9p: validate PDU length
From: Dominique Martinet @ 2018-07-24 3:57 UTC (permalink / raw)
To: Tomas Bortoli
Cc: ericvh, rminnich, lucho, davem, v9fs-developer, netdev,
linux-kernel, syzkaller
In-Reply-To: <20180723154404.2406-1-tomasbortoli@gmail.com>
Tomas Bortoli wrote on Mon, Jul 23, 2018:
> This commit adds length check for the PDU size.
> The size contained in the header has to match the actual size,
> except for TCP (trans_fd.c) where actual length is not known ahead
> and the header's length will be checked only against the validity
> range.
>
> Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
> Reported-by: syzbot+65c6b72f284a39d416b4@syzkaller.appspotmail.com
Ok, I've run some more in-depth testing this time and all appear in
order.
Like I said last time, I cannot test the xen transport - if someone can
point me to how to set it up or run some tests semi-regularily it'd be
great.
Meanwhile, code looks good and appears to work, so I'll take this
patch unless someone yells
> ---
> net/9p/client.c | 25 ++++++++++++++++---------
> net/9p/trans_fd.c | 5 ++++-
> net/9p/trans_rdma.c | 1 +
> net/9p/trans_virtio.c | 4 +++-
> 4 files changed, 24 insertions(+), 11 deletions(-)
>
> diff --git a/net/9p/client.c b/net/9p/client.c
> index 18c5271910dc..92240ccf476b 100644
> --- a/net/9p/client.c
> +++ b/net/9p/client.c
> @@ -477,20 +477,11 @@ p9_parse_header(struct p9_fcall *pdu, int32_t *size, int8_t *type, int16_t *tag,
> int err;
>
> pdu->offset = 0;
> - if (pdu->size == 0)
> - pdu->size = 7;
>
> err = p9pdu_readf(pdu, 0, "dbw", &r_size, &r_type, &r_tag);
> if (err)
> goto rewind_and_exit;
>
> - pdu->size = r_size;
> - pdu->id = r_type;
> - pdu->tag = r_tag;
> -
> - p9_debug(P9_DEBUG_9P, "<<< size=%d type: %d tag: %d\n",
> - pdu->size, pdu->id, pdu->tag);
> -
> if (type)
> *type = r_type;
> if (tag)
> @@ -498,6 +489,16 @@ p9_parse_header(struct p9_fcall *pdu, int32_t *size, int8_t *type, int16_t *tag,
> if (size)
> *size = r_size;
>
> + if (pdu->size != r_size || r_size < 7) {
> + err = -EINVAL;
> + goto rewind_and_exit;
> + }
> +
> + pdu->id = r_type;
> + pdu->tag = r_tag;
> +
> + p9_debug(P9_DEBUG_9P, "<<< size=%d type: %d tag: %d\n",
> + pdu->size, pdu->id, pdu->tag);
>
> rewind_and_exit:
> if (rewind)
> @@ -524,6 +525,12 @@ static int p9_check_errors(struct p9_client *c, struct p9_req_t *req)
> int ecode;
>
> err = p9_parse_header(req->rc, NULL, &type, NULL, 0);
> + if (req->rc->size >= c->msize) {
> + p9_debug(P9_DEBUG_ERROR,
> + "requested packet size too big: %d\n",
> + req->rc->size);
> + return -EIO;
Indentation here looks wrong, I took the liberty of deindenting that
return in my tree.
> + }
> /*
> * dump the response from server
> * This should be after check errors which poplulate pdu_fcall.
> diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
> index 588bf88c3305..65533c437b7f 100644
> --- a/net/9p/trans_fd.c
> +++ b/net/9p/trans_fd.c
> @@ -324,7 +324,9 @@ static void p9_read_work(struct work_struct *work)
> if ((!m->req) && (m->rc.offset == m->rc.capacity)) {
> p9_debug(P9_DEBUG_TRANS, "got new header\n");
>
> - err = p9_parse_header(&m->rc, NULL, NULL, NULL, 0);
> + /* Header size */
> + m->rc.size = 7;
> + err = p9_parse_header(&m->rc, &m->rc.size, NULL, NULL, 0);
> if (err) {
> p9_debug(P9_DEBUG_ERROR,
> "error parsing header: %d\n", err);
> @@ -369,6 +371,7 @@ static void p9_read_work(struct work_struct *work)
> */
> if ((m->req) && (m->rc.offset == m->rc.capacity)) {
> p9_debug(P9_DEBUG_TRANS, "got new packet\n");
> + m->req->rc->size = m->rc.offset;
> spin_lock(&m->client->lock);
> if (m->req->status != REQ_STATUS_ERROR)
> status = REQ_STATUS_RCVD;
> diff --git a/net/9p/trans_rdma.c b/net/9p/trans_rdma.c
> index 3d414acb7015..2649b2ebf961 100644
> --- a/net/9p/trans_rdma.c
> +++ b/net/9p/trans_rdma.c
> @@ -320,6 +320,7 @@ recv_done(struct ib_cq *cq, struct ib_wc *wc)
> if (wc->status != IB_WC_SUCCESS)
> goto err_out;
>
> + c->rc->size = wc->byte_len;
> err = p9_parse_header(c->rc, NULL, NULL, &tag, 1);
> if (err)
> goto err_out;
> diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
> index 05006cbb3361..fc6dc9ca86a4 100644
> --- a/net/9p/trans_virtio.c
> +++ b/net/9p/trans_virtio.c
> @@ -159,8 +159,10 @@ static void req_done(struct virtqueue *vq)
> spin_unlock_irqrestore(&chan->lock, flags);
> /* Wakeup if anyone waiting for VirtIO ring space. */
> wake_up(chan->vc_wq);
> - if (len)
> + if (len) {
> + req->rc->size = len;
> p9_client_cb(chan->client, req, REQ_STATUS_RCVD);
> + }
> }
> }
>
--
Dominique Martinet
^ permalink raw reply
* Re: [PATCH v3 bpf-next 6/8] xdp: Add a flag for disabling napi_direct of xdp_return_frame in xdp_mem_info
From: Toshiaki Makita @ 2018-07-24 2:43 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Toshiaki Makita, netdev, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer
In-Reply-To: <20180723182247.494ccb07@cakuba.netronome.com>
On 2018/07/24 10:22, Jakub Kicinski wrote:
> On Mon, 23 Jul 2018 00:13:06 +0900, Toshiaki Makita wrote:
>> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>
>> We need some mechanism to disable napi_direct on calling
>> xdp_return_frame_rx_napi() from some context.
>> When veth gets support of XDP_REDIRECT, it will redirects packets which
>> are redirected from other devices. On redirection veth will reuse
>> xdp_mem_info of the redirection source device to make return_frame work.
>> But in this case .ndo_xdp_xmit() called from veth redirection uses
>> xdp_mem_info which is not guarded by NAPI, because the .ndo_xdp_xmit is
>> not called directly from the rxq which owns the xdp_mem_info.
>>
>> This approach introduces a flag in xdp_mem_info to indicate that
>> napi_direct should be disabled even when _rx_napi variant is used.
>>
>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>
> To be clear - you will modify flags of the original source device if it
> ever redirected a frame to a software device like veth? Seems a bit
> heavy handed. The xdp_return_frame_rx_napi() is only really used on
> error paths, but still.. Also as you note the original NAPI can run
> concurrently with your veth dest one, but also with NAPIs of other veth
> devices, so the non-atomic xdp.rxq->mem.flags |= XDP_MEM_RF_NO_DIRECT;
> makes me worried.
xdp_mem_info is copied in xdp_frame in convert_to_xdp_frame() so the
field is local to the frame. Changing flags affects only the frame.
xdp.rxq is local to NAPI thread, so no worries about atomicity.
> Would you mind elaborating why not handle the RX completely in the NAPI
> context of the original device?
Originally it was difficult to implement .ndo_xdp_xmit() and
.ndo_xdp_flush() model without creating NAPI in veth. Now it is changed
so I'm not sure how difficult it is at this point.
But in any case I want to avoid stack inflation by veth NAPI. (Imagine
some misconfiguration like calling XDP_TX on both side of veth...)
>
>> diff --git a/include/net/xdp.h b/include/net/xdp.h
>> index fcb033f51d8c..1d1bc6553ff2 100644
>> --- a/include/net/xdp.h
>> +++ b/include/net/xdp.h
>> @@ -41,6 +41,9 @@ enum xdp_mem_type {
>> MEM_TYPE_MAX,
>> };
>>
>> +/* XDP flags for xdp_mem_info */
>> +#define XDP_MEM_RF_NO_DIRECT BIT(0) /* don't use napi_direct */
>> +
>> /* XDP flags for ndo_xdp_xmit */
>> #define XDP_XMIT_FLUSH (1U << 0) /* doorbell signal consumer */
>> #define XDP_XMIT_FLAGS_MASK XDP_XMIT_FLUSH
>> @@ -48,6 +51,7 @@ enum xdp_mem_type {
>> struct xdp_mem_info {
>> u32 type; /* enum xdp_mem_type, but known size type */
>> u32 id;
>> + u32 flags;
>> };
>>
>> struct page_pool;
>> diff --git a/net/core/xdp.c b/net/core/xdp.c
>> index 57285383ed00..1426c608fd75 100644
>> --- a/net/core/xdp.c
>> +++ b/net/core/xdp.c
>> @@ -330,10 +330,12 @@ static void __xdp_return(void *data, struct xdp_mem_info *mem, bool napi_direct,
>> /* mem->id is valid, checked in xdp_rxq_info_reg_mem_model() */
>> xa = rhashtable_lookup(mem_id_ht, &mem->id, mem_id_rht_params);
>> page = virt_to_head_page(data);
>> - if (xa)
>> + if (xa) {
>> + napi_direct &= !(mem->flags & XDP_MEM_RF_NO_DIRECT);
>> page_pool_put_page(xa->page_pool, page, napi_direct);
>> - else
>> + } else {
>> put_page(page);
>> + }
>> rcu_read_unlock();
>> break;
>> case MEM_TYPE_PAGE_SHARED:
>
>
>
--
Toshiaki Makita
^ permalink raw reply
* Re: [PATCH rdma-next v2 0/8] Support mlx5 flow steering with RAW data
From: Jason Gunthorpe @ 2018-07-24 2:42 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Leon Romanovsky, RDMA mailing list, Yishai Hadas,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180723122512.20967-1-leon@kernel.org>
On Mon, Jul 23, 2018 at 03:25:04PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Changelog:
> v1->v2:
> * Fix matcher to use the correct size.
> * Rephrase commit log of the first patch.
> v0->v1:
> * Fixed ADD_UVERBS_ATTRIBUTES_SIMPLE macro to pass the real address.
> ?* Replaced UA_ALLOC_AND_COPY to regular copy_from
> * Added UVERBS_ATTR_NO_DATA new macro for cleaner code.
> * Used ib_dev from uobj when it exists.
> * ib_is_destroy_retryable was replaced by ib_destroy_usecnt
>
> >From Yishai:
>
> This series introduces vendor create and destroy flow methods on the
> uverbs flow object by using the KABI infra-structure.
>
> It's done in a way that enables the driver to get its specific device
> attributes in a raw data to match its underlay specification while still
> using the generic ib_flow object for cleanup and code sharing.
>
> In addition, a specific mlx5 matcher object and its create/destroy
> methods were introduced. This object matches the underlay flow steering
> mask specification and is used as part of mlx5 create flow input data.
>
> This series supports IB_QP/TIR as its flow steering destination as
> applicable today via the ib_create_flow API, however, it adds also an
> option to work with DEVX object which its destination can be both TIR
> and flow table.
>
> Few changes were done in the mlx5 core layer to support forward
> compatible for the device specification raw data and to support flow
> table when the DEVX destination is used.
>
> As part of this series the default IB destroy handler
> (i.e. uverbs_destroy_def_handler()) was exposed from IB core to be
> used by the drivers and existing code was refactored to use it.
>
> Thanks
>
> Yishai Hadas (8):
> net/mlx5: Add forward compatible support for the FTE match data
> net/mlx5: Add support for flow table destination number
> IB/mlx5: Introduce flow steering matcher object
> IB: Consider ib_flow creation by the KABI infrastructure
> IB/mlx5: Introduce vendor create and destroy flow methods
> IB/mlx5: Support adding flow steering rule by raw data
> IB/mlx5: Add support for a flow table destination
> IB/mlx5: Expose vendor flow trees
This seems fine to me. Can you send the mlx5 shared branch for the
first two patches?
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH net-next v6 3/4] net: vhost: factor out busy polling logic to vhost_net_busy_poll()
From: Toshiaki Makita @ 2018-07-24 3:41 UTC (permalink / raw)
To: Tonghao Zhang
Cc: Linux Kernel Network Developers, toshiaki.makita1, virtualization,
mst
In-Reply-To: <CAMDZJNVVJs35kuvktTxn+mmDz7db+1K-kfuOoMUn9Z=WoayUVw@mail.gmail.com>
On 2018/07/24 12:28, Tonghao Zhang wrote:
> On Tue, Jul 24, 2018 at 10:53 AM Toshiaki Makita
> <makita.toshiaki@lab.ntt.co.jp> wrote:
>>
>> On 2018/07/24 2:31, Tonghao Zhang wrote:
>>> On Mon, Jul 23, 2018 at 10:20 PM Toshiaki Makita
>>> <toshiaki.makita1@gmail.com> wrote:
>>>>
>>>> On 18/07/23 (月) 21:43, Tonghao Zhang wrote:
>>>>> On Mon, Jul 23, 2018 at 5:58 PM Toshiaki Makita
>>>>> <makita.toshiaki@lab.ntt.co.jp> wrote:
>>>>>>
>>>>>> On 2018/07/22 3:04, xiangxia.m.yue@gmail.com wrote:
>>>>>>> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>>>>>>>
>>>>>>> Factor out generic busy polling logic and will be
>>>>>>> used for in tx path in the next patch. And with the patch,
>>>>>>> qemu can set differently the busyloop_timeout for rx queue.
>>>>>>>
>>>>>>> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>>>>>>> ---
>>>>>> ...
>>>>>>> +static void vhost_net_busy_poll_vq_check(struct vhost_net *net,
>>>>>>> + struct vhost_virtqueue *rvq,
>>>>>>> + struct vhost_virtqueue *tvq,
>>>>>>> + bool rx)
>>>>>>> +{
>>>>>>> + struct socket *sock = rvq->private_data;
>>>>>>> +
>>>>>>> + if (rx) {
>>>>>>> + if (!vhost_vq_avail_empty(&net->dev, tvq)) {
>>>>>>> + vhost_poll_queue(&tvq->poll);
>>>>>>> + } else if (unlikely(vhost_enable_notify(&net->dev, tvq))) {
>>>>>>> + vhost_disable_notify(&net->dev, tvq);
>>>>>>> + vhost_poll_queue(&tvq->poll);
>>>>>>> + }
>>>>>>> + } else if ((sock && sk_has_rx_data(sock->sk)) &&
>>>>>>> + !vhost_vq_avail_empty(&net->dev, rvq)) {
>>>>>>> + vhost_poll_queue(&rvq->poll);
>>>>>>
>>>>>> Now we wait for vq_avail for rx as well, I think you cannot skip
>>>>>> vhost_enable_notify() on tx. Probably you might want to do:
>>>>> I think vhost_enable_notify is needed.
>>>>>
>>>>>> } else if (sock && sk_has_rx_data(sock->sk)) {
>>>>>> if (!vhost_vq_avail_empty(&net->dev, rvq)) {
>>>>>> vhost_poll_queue(&rvq->poll);
>>>>>> } else if (unlikely(vhost_enable_notify(&net->dev, rvq))) {
>>>>>> vhost_disable_notify(&net->dev, rvq);
>>>>>> vhost_poll_queue(&rvq->poll);
>>>>>> }
>>>>>> }
>>>>> As Jason review as before, we only want rx kick when packet is pending at
>>>>> socket but we're out of available buffers. So we just enable notify,
>>>>> but not poll it ?
>>>>>
>>>>> } else if ((sock && sk_has_rx_data(sock->sk)) &&
>>>>> !vhost_vq_avail_empty(&net->dev, rvq)) {
>>>>> vhost_poll_queue(&rvq->poll);
>>>>> else {
>>>>> vhost_enable_notify(&net->dev, rvq);
>>>>> }
>>>>
>>>> When vhost_enable_notify() returns true the avail becomes non-empty
>>>> while we are enabling notify. We may delay the rx process if we don't
>>>> check the return value of vhost_enable_notify().
>>> I got it thanks.
>>>>>> Also it's better to care vhost_net_disable_vq()/vhost_net_enable_vq() on tx?
>>>>> I cant find why it is better, if necessary, we can do it.
>>>>
>>>> The reason is pretty simple... we are busypolling the socket so we don't
>>>> need rx wakeups during it?
>>> OK, but one question, how about rx? do we use the
>>> vhost_net_disable_vq/vhost_net_ensable_vq on rx ?
>>
>> If we are busypolling the sock tx buf? I'm not sure if polling it
>> improves the performance.
> Not the sock tx buff, when we are busypolling in handle_rx, we will
> check the tx vring via vhost_vq_avail_empty.
> So, should we the disable tvq, e.g. vhost_net_disable_vq(net, tvq)?> --
When you want to stop vq kicks from the guest you should call
vhost_disable_notify() and when you want to stop vq wakeups from the
socket you should call vhost_net_disable_vq().
You are polling vq_avail so you want to stop vq kicks thus
vhost_disable_notify() is needed and it is already called.
--
Toshiaki Makita
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: btf: fix inconsistent IS_ERR and PTR_ERR
From: Jakub Kicinski @ 2018-07-24 3:40 UTC (permalink / raw)
To: YueHaibing
Cc: ast, daniel, quentin.monnet, bhole_prashant_q7, osk, linux-kernel,
netdev, davem
In-Reply-To: <20180724025524.22012-1-yuehaibing@huawei.com>
On Tue, 24 Jul 2018 10:55:24 +0800, YueHaibing wrote:
> Fix inconsistent IS_ERR and PTR_ERR in get_btf,
> the proper pointer to be passed as argument is '*btf'
>
> This issue was detected with the help of Coccinelle.
>
> Fixes: 2d3feca8c44f ("bpf: btf: print map dump and lookup with btf info")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
FWIW:
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Thanks!
^ permalink raw reply
* Re: [PATCH v5 net-next 0/6] net: ethernet: ti: cpsw: add MQPRIO and CBS Qdisc offload
From: David Miller @ 2018-07-24 3:38 UTC (permalink / raw)
To: ivan.khoronzhuk
Cc: grygorii.strashko, corbet, akpm, netdev, linux-doc, linux-kernel,
linux-omap, vinicius.gomes, henrik, jesus.sanchez-palencia,
ilias.apalodimas, p-varis, spatton, francois.ozog, yogeshs,
nsekhar, andrew
In-Reply-To: <20180723212634.3219-1-ivan.khoronzhuk@linaro.org>
From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Date: Tue, 24 Jul 2018 00:26:28 +0300
> This series adds MQPRIO and CBS Qdisc offload for TI cpsw driver.
> It potentially can be used in audio video bridging (AVB) and time
> sensitive networking (TSN).
>
> Patchset was tested on AM572x EVM and BBB boards. Last patch from this
> series adds detailed description of configuration with examples. For
> consistency reasons, in role of talker and listener, tools from
> patchset "TSN: Add qdisc based config interface for CBS" were used and
> can be seen here: https://www.spinics.net/lists/netdev/msg460869.html
>
> Based on net-next/master
Series applied, thanks Ivan.
^ permalink raw reply
* Re: [PATCH v3 bpf-next 5/8] veth: Add ndo_xdp_xmit
From: Toshiaki Makita @ 2018-07-24 2:24 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Toshiaki Makita, netdev, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer
In-Reply-To: <20180723180246.1836bc11@cakuba.netronome.com>
On 2018/07/24 10:02, Jakub Kicinski wrote:
> On Mon, 23 Jul 2018 00:13:05 +0900, Toshiaki Makita wrote:
>> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>
>> This allows NIC's XDP to redirect packets to veth. The destination veth
>> device enqueues redirected packets to the napi ring of its peer, then
>> they are processed by XDP on its peer veth device.
>> This can be thought as calling another XDP program by XDP program using
>> REDIRECT, when the peer enables driver XDP.
>>
>> Note that when the peer veth device does not set driver xdp, redirected
>> packets will be dropped because the peer is not ready for NAPI.
...
>> +static int veth_xdp_xmit(struct net_device *dev, int n,
>> + struct xdp_frame **frames, u32 flags)
>> +{
>> + struct veth_priv *rcv_priv, *priv = netdev_priv(dev);
>> + struct net_device *rcv;
>> + int i, drops = 0;
>> +
>> + if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK))
>> + return -EINVAL;
>> +
>> + rcv = rcu_dereference(priv->peer);
>> + if (unlikely(!rcv))
>> + return -ENXIO;
>> +
>> + rcv_priv = netdev_priv(rcv);
>> + /* xdp_ring is initialized on receive side? */
>> + if (!rcu_access_pointer(rcv_priv->xdp_prog))
>> + return -ENXIO;
>> +
>> + spin_lock(&rcv_priv->xdp_ring.producer_lock);
>> + for (i = 0; i < n; i++) {
>> + struct xdp_frame *frame = frames[i];
>> + void *ptr = veth_xdp_to_ptr(frame);
>> +
>> + if (unlikely(xdp_ok_fwd_dev(rcv, frame->len) ||
>> + __ptr_ring_produce(&rcv_priv->xdp_ring, ptr))) {
>
> Would you mind sparing a few more words how this is safe vs the
> .ndo_close() on the peer? Personally I'm a bit uncomfortable with the
> IFF_UP check in xdp_ok_fwd_dev(), I'm not sure what's supposed to
> guarantee the device doesn't go down right after that check, or is
> already down, but netdev->flags are not atomic...
Actually it is guarded by RCU. On closing the device rcv_priv->xdp_prog
is set to be NULL, and synchronize_net() is called from within
netif_napi_del(). Then ptr_ring is cleaned-up.
xdp_ok_fwd_dev() is doing the same check as non-XDP case, but it may not
be appropriate because IFF_UP check here is not usable as you say.
>
>> + xdp_return_frame_rx_napi(frame);
>> + drops++;
>> + }
>> + }
>> + spin_unlock(&rcv_priv->xdp_ring.producer_lock);
>> +
>> + if (flags & XDP_XMIT_FLUSH)
>> + __veth_xdp_flush(rcv_priv);
>> +
>> + return n - drops;
>> +}
>> +
>> static struct sk_buff *veth_xdp_rcv_one(struct veth_priv *priv,
>> struct xdp_frame *frame)
>> {
>> @@ -760,6 +804,7 @@ static const struct net_device_ops veth_netdev_ops = {
>> .ndo_features_check = passthru_features_check,
>> .ndo_set_rx_headroom = veth_set_rx_headroom,
>> .ndo_bpf = veth_xdp,
>> + .ndo_xdp_xmit = veth_xdp_xmit,
>> };
>>
>> #define VETH_FEATURES (NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_HW_CSUM | \
>
>
>
--
Toshiaki Makita
^ permalink raw reply
* Re: [PATCH net-next v6 3/4] net: vhost: factor out busy polling logic to vhost_net_busy_poll()
From: Tonghao Zhang @ 2018-07-24 3:28 UTC (permalink / raw)
To: makita.toshiaki
Cc: Linux Kernel Network Developers, toshiaki.makita1, virtualization,
mst
In-Reply-To: <14d01d2d-0eb8-172b-1c53-7dadc5fffbac@lab.ntt.co.jp>
On Tue, Jul 24, 2018 at 10:53 AM Toshiaki Makita
<makita.toshiaki@lab.ntt.co.jp> wrote:
>
> On 2018/07/24 2:31, Tonghao Zhang wrote:
> > On Mon, Jul 23, 2018 at 10:20 PM Toshiaki Makita
> > <toshiaki.makita1@gmail.com> wrote:
> >>
> >> On 18/07/23 (月) 21:43, Tonghao Zhang wrote:
> >>> On Mon, Jul 23, 2018 at 5:58 PM Toshiaki Makita
> >>> <makita.toshiaki@lab.ntt.co.jp> wrote:
> >>>>
> >>>> On 2018/07/22 3:04, xiangxia.m.yue@gmail.com wrote:
> >>>>> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> >>>>>
> >>>>> Factor out generic busy polling logic and will be
> >>>>> used for in tx path in the next patch. And with the patch,
> >>>>> qemu can set differently the busyloop_timeout for rx queue.
> >>>>>
> >>>>> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> >>>>> ---
> >>>> ...
> >>>>> +static void vhost_net_busy_poll_vq_check(struct vhost_net *net,
> >>>>> + struct vhost_virtqueue *rvq,
> >>>>> + struct vhost_virtqueue *tvq,
> >>>>> + bool rx)
> >>>>> +{
> >>>>> + struct socket *sock = rvq->private_data;
> >>>>> +
> >>>>> + if (rx) {
> >>>>> + if (!vhost_vq_avail_empty(&net->dev, tvq)) {
> >>>>> + vhost_poll_queue(&tvq->poll);
> >>>>> + } else if (unlikely(vhost_enable_notify(&net->dev, tvq))) {
> >>>>> + vhost_disable_notify(&net->dev, tvq);
> >>>>> + vhost_poll_queue(&tvq->poll);
> >>>>> + }
> >>>>> + } else if ((sock && sk_has_rx_data(sock->sk)) &&
> >>>>> + !vhost_vq_avail_empty(&net->dev, rvq)) {
> >>>>> + vhost_poll_queue(&rvq->poll);
> >>>>
> >>>> Now we wait for vq_avail for rx as well, I think you cannot skip
> >>>> vhost_enable_notify() on tx. Probably you might want to do:
> >>> I think vhost_enable_notify is needed.
> >>>
> >>>> } else if (sock && sk_has_rx_data(sock->sk)) {
> >>>> if (!vhost_vq_avail_empty(&net->dev, rvq)) {
> >>>> vhost_poll_queue(&rvq->poll);
> >>>> } else if (unlikely(vhost_enable_notify(&net->dev, rvq))) {
> >>>> vhost_disable_notify(&net->dev, rvq);
> >>>> vhost_poll_queue(&rvq->poll);
> >>>> }
> >>>> }
> >>> As Jason review as before, we only want rx kick when packet is pending at
> >>> socket but we're out of available buffers. So we just enable notify,
> >>> but not poll it ?
> >>>
> >>> } else if ((sock && sk_has_rx_data(sock->sk)) &&
> >>> !vhost_vq_avail_empty(&net->dev, rvq)) {
> >>> vhost_poll_queue(&rvq->poll);
> >>> else {
> >>> vhost_enable_notify(&net->dev, rvq);
> >>> }
> >>
> >> When vhost_enable_notify() returns true the avail becomes non-empty
> >> while we are enabling notify. We may delay the rx process if we don't
> >> check the return value of vhost_enable_notify().
> > I got it thanks.
> >>>> Also it's better to care vhost_net_disable_vq()/vhost_net_enable_vq() on tx?
> >>> I cant find why it is better, if necessary, we can do it.
> >>
> >> The reason is pretty simple... we are busypolling the socket so we don't
> >> need rx wakeups during it?
> > OK, but one question, how about rx? do we use the
> > vhost_net_disable_vq/vhost_net_ensable_vq on rx ?
>
> If we are busypolling the sock tx buf? I'm not sure if polling it
> improves the performance.
Not the sock tx buff, when we are busypolling in handle_rx, we will
check the tx vring via vhost_vq_avail_empty.
So, should we the disable tvq, e.g. vhost_net_disable_vq(net, tvq)?> --
> Toshiaki Makita
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH net-next] tcp: ack immediately when a cwr packet arrives
From: Daniel Borkmann @ 2018-07-24 2:23 UTC (permalink / raw)
To: Neal Cardwell, Lawrence Brakmo
Cc: Netdev, Kernel Team, ast, Yuchung Cheng, Eric Dumazet
In-Reply-To: <CADVnQynGT7neCE5d6WaGQYs2WtBLjVhVXrOoJu3PYQDx-hTmjg@mail.gmail.com>
On 07/24/2018 04:15 AM, Neal Cardwell wrote:
> On Mon, Jul 23, 2018 at 8:49 PM Lawrence Brakmo <brakmo@fb.com> wrote:
>>
>> We observed high 99 and 99.9% latencies when doing RPCs with DCTCP. The
>> problem is triggered when the last packet of a request arrives CE
>> marked. The reply will carry the ECE mark causing TCP to shrink its cwnd
>> to 1 (because there are no packets in flight). When the 1st packet of
>> the next request arrives, the ACK was sometimes delayed even though it
>> is CWR marked, adding up to 40ms to the RPC latency.
>>
>> This patch insures that CWR marked data packets arriving will be acked
>> immediately.
> ...
>> Modified based on comments by Neal Cardwell <ncardwell@google.com>
>>
>> Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
>> ---
>> net/ipv4/tcp_input.c | 9 ++++++++-
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> Seems like a nice mechanism to have, IMHO.
>
> Acked-by: Neal Cardwell <ncardwell@google.com>
Should this go to net tree instead where all the other fixes went?
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: btf: fix inconsistent IS_ERR and PTR_ERR
From: David Miller @ 2018-07-24 3:20 UTC (permalink / raw)
To: yuehaibing
Cc: ast, daniel, quentin.monnet, jakub.kicinski, bhole_prashant_q7,
osk, linux-kernel, netdev
In-Reply-To: <20180724025524.22012-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Tue, 24 Jul 2018 10:55:24 +0800
> Fix inconsistent IS_ERR and PTR_ERR in get_btf,
> the proper pointer to be passed as argument is '*btf'
>
> This issue was detected with the help of Coccinelle.
>
> Fixes: 2d3feca8c44f ("bpf: btf: print map dump and lookup with btf info")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH net-next] tcp: ack immediately when a cwr packet arrives
From: Neal Cardwell @ 2018-07-24 2:15 UTC (permalink / raw)
To: Lawrence Brakmo; +Cc: Netdev, Kernel Team, ast, Yuchung Cheng, Eric Dumazet
In-Reply-To: <20180724004939.2874202-1-brakmo@fb.com>
On Mon, Jul 23, 2018 at 8:49 PM Lawrence Brakmo <brakmo@fb.com> wrote:
>
> We observed high 99 and 99.9% latencies when doing RPCs with DCTCP. The
> problem is triggered when the last packet of a request arrives CE
> marked. The reply will carry the ECE mark causing TCP to shrink its cwnd
> to 1 (because there are no packets in flight). When the 1st packet of
> the next request arrives, the ACK was sometimes delayed even though it
> is CWR marked, adding up to 40ms to the RPC latency.
>
> This patch insures that CWR marked data packets arriving will be acked
> immediately.
...
> Modified based on comments by Neal Cardwell <ncardwell@google.com>
>
> Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
> ---
> net/ipv4/tcp_input.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
Seems like a nice mechanism to have, IMHO.
Acked-by: Neal Cardwell <ncardwell@google.com>
Thanks!
neal
^ permalink raw reply
* Re: [PATCH v3 bpf-next 5/8] veth: Add ndo_xdp_xmit
From: Toshiaki Makita @ 2018-07-24 2:11 UTC (permalink / raw)
To: Jakub Kicinski, Toshiaki Makita
Cc: netdev, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, tariqt
In-Reply-To: <20180723180246.1836bc11@cakuba.netronome.com>
On 2018/07/24 10:02, Jakub Kicinski wrote:
> On Mon, 23 Jul 2018 00:13:05 +0900, Toshiaki Makita wrote:
>> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>
>> This allows NIC's XDP to redirect packets to veth. The destination veth
>> device enqueues redirected packets to the napi ring of its peer, then
>> they are processed by XDP on its peer veth device.
>> This can be thought as calling another XDP program by XDP program using
>> REDIRECT, when the peer enables driver XDP.
>>
>> Note that when the peer veth device does not set driver xdp, redirected
>> packets will be dropped because the peer is not ready for NAPI.
>
> Often we can't redirect to devices which don't have am xdp program
> installed. In your case we can't redirect unless the peer of the
> target doesn't have a program installed? :(
Right. I tried to avoid this case by converting xdp_frames to skb but
realized that should not be done.
https://patchwork.ozlabs.org/patch/903536/
> Perhaps it is time to reconsider what Saeed once asked for, a flag or
> attribute to enable being the destination of a XDP_REDIRECT.
Yes, something will be necessary. Jesper said Tariq had some ideas to
implement it.
>
>> v2:
>> - Drop the part converting xdp_frame into skb when XDP is not enabled.
>> - Implement bulk interface of ndo_xdp_xmit.
>> - Implement XDP_XMIT_FLUSH bit and drop ndo_xdp_flush.
>>
>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>> ---
>> drivers/net/veth.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 45 insertions(+)
>>
>> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
>> index 4be75c58bc6a..57187e955fea 100644
>> --- a/drivers/net/veth.c
>> +++ b/drivers/net/veth.c
>> @@ -17,6 +17,7 @@
>> #include <net/rtnetlink.h>
>> #include <net/dst.h>
>> #include <net/xfrm.h>
>> +#include <net/xdp.h>
>> #include <linux/veth.h>
>> #include <linux/module.h>
>> #include <linux/bpf.h>
>> @@ -125,6 +126,11 @@ static void *veth_ptr_to_xdp(void *ptr)
>> return (void *)((unsigned long)ptr & ~VETH_XDP_FLAG);
>> }
>>
>> +static void *veth_xdp_to_ptr(void *ptr)
>> +{
>> + return (void *)((unsigned long)ptr | VETH_XDP_FLAG);
>> +}
>> +
>> static void veth_ptr_free(void *ptr)
>> {
>> if (veth_is_xdp_frame(ptr))
>> @@ -267,6 +273,44 @@ static struct sk_buff *veth_build_skb(void *head, int headroom, int len,
>> return skb;
>> }
>>
>> +static int veth_xdp_xmit(struct net_device *dev, int n,
>> + struct xdp_frame **frames, u32 flags)
>> +{
>> + struct veth_priv *rcv_priv, *priv = netdev_priv(dev);
>> + struct net_device *rcv;
>> + int i, drops = 0;
>> +
>> + if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK))
>> + return -EINVAL;
>> +
>> + rcv = rcu_dereference(priv->peer);
>> + if (unlikely(!rcv))
>> + return -ENXIO;
>> +
>> + rcv_priv = netdev_priv(rcv);
>> + /* xdp_ring is initialized on receive side? */
>> + if (!rcu_access_pointer(rcv_priv->xdp_prog))
>> + return -ENXIO;
>> +
>> + spin_lock(&rcv_priv->xdp_ring.producer_lock);
>> + for (i = 0; i < n; i++) {
>> + struct xdp_frame *frame = frames[i];
>> + void *ptr = veth_xdp_to_ptr(frame);
>> +
>> + if (unlikely(xdp_ok_fwd_dev(rcv, frame->len) ||
>> + __ptr_ring_produce(&rcv_priv->xdp_ring, ptr))) {
>
> Would you mind sparing a few more words how this is safe vs the
> .ndo_close() on the peer? Personally I'm a bit uncomfortable with the
> IFF_UP check in xdp_ok_fwd_dev(), I'm not sure what's supposed to
> guarantee the device doesn't go down right after that check, or is
> already down, but netdev->flags are not atomic...
>
>> + xdp_return_frame_rx_napi(frame);
>> + drops++;
>> + }
>> + }
>> + spin_unlock(&rcv_priv->xdp_ring.producer_lock);
>> +
>> + if (flags & XDP_XMIT_FLUSH)
>> + __veth_xdp_flush(rcv_priv);
>> +
>> + return n - drops;
>> +}
>> +
>> static struct sk_buff *veth_xdp_rcv_one(struct veth_priv *priv,
>> struct xdp_frame *frame)
>> {
>> @@ -760,6 +804,7 @@ static const struct net_device_ops veth_netdev_ops = {
>> .ndo_features_check = passthru_features_check,
>> .ndo_set_rx_headroom = veth_set_rx_headroom,
>> .ndo_bpf = veth_xdp,
>> + .ndo_xdp_xmit = veth_xdp_xmit,
>> };
>>
>> #define VETH_FEATURES (NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_HW_CSUM | \
>
>
>
--
Toshiaki Makita
^ permalink raw reply
* Re: [PATCH v3 bpf-next 5/8] veth: Add ndo_xdp_xmit
From: Toshiaki Makita @ 2018-07-24 1:59 UTC (permalink / raw)
To: Toshiaki Makita
Cc: kbuild test robot, kbuild-all, netdev, Alexei Starovoitov,
Daniel Borkmann, Jesper Dangaard Brouer
In-Reply-To: <201807240711.kbMKpUVb%fengguang.wu@intel.com>
On 2018/07/24 9:19, kbuild test robot wrote:
> Hi Toshiaki,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on bpf-next/master]
>
> url: https://github.com/0day-ci/linux/commits/Toshiaki-Makita/veth-Driver-XDP/20180724-065517
> base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
> config: i386-randconfig-x001-201829 (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
> In file included from include/linux/kernel.h:10:0,
> from include/linux/list.h:9,
> from include/linux/timer.h:5,
> from include/linux/netdevice.h:28,
> from drivers//net/veth.c:11:
> drivers//net/veth.c: In function 'veth_xdp_xmit':
>>> drivers//net/veth.c:300:16: error: implicit declaration of function 'xdp_ok_fwd_dev' [-Werror=implicit-function-declaration]
> if (unlikely(xdp_ok_fwd_dev(rcv, frame->len) ||
This is because this series depends on commit d8d7218ad842 ("xdp:
XDP_REDIRECT should check IFF_UP and MTU") which is currently in DaveM's
net-next tree, as I noted in the cover letter.
--
Toshiaki Makita
^ permalink raw reply
* Re: [PATCH v3 bpf-next 3/8] veth: Avoid drops by oversized packets when XDP is enabled
From: Toshiaki Makita @ 2018-07-24 1:56 UTC (permalink / raw)
To: Jakub Kicinski, Toshiaki Makita
Cc: netdev, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer
In-Reply-To: <20180723172707.74a8acfa@cakuba.netronome.com>
On 2018/07/24 9:27, Jakub Kicinski wrote:
> On Mon, 23 Jul 2018 00:13:03 +0900, Toshiaki Makita wrote:
>> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>
>> All oversized packets including GSO packets are dropped if XDP is
>> enabled on receiver side, so don't send such packets from peer.
>>
>> Drop TSO and SCTP fragmentation features so that veth devices themselves
>> segment packets with XDP enabled. Also cap MTU accordingly.
>>
>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>
> Is there any precedence for fixing up features and MTU like this? Most
> drivers just refuse to install the program if settings are incompatible.
I don't know any precedence. I can refuse the program on installing it
when features and MTU are not appropriate. Is it preferred?
Note that with current implementation wanted_features are not touched so
features will be restored when the XDP program is removed. MTU will not
be restored though, as I do not remember the original MTU.
>> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
>> index 78fa08cb6e24..f5b72e937d9d 100644
>> --- a/drivers/net/veth.c
>> +++ b/drivers/net/veth.c
>> @@ -542,6 +542,23 @@ static int veth_get_iflink(const struct net_device *dev)
>> return iflink;
>> }
>>
>> +static netdev_features_t veth_fix_features(struct net_device *dev,
>> + netdev_features_t features)
>> +{
>> + struct veth_priv *priv = netdev_priv(dev);
>> + struct net_device *peer;
>> +
>> + peer = rtnl_dereference(priv->peer);
>> + if (peer) {
>> + struct veth_priv *peer_priv = netdev_priv(peer);
>> +
>> + if (peer_priv->_xdp_prog)
>> + features &= ~NETIF_F_GSO_SOFTWARE;
>> + }
>> +
>> + return features;
>> +}
>> +
>> static void veth_set_rx_headroom(struct net_device *dev, int new_hr)
>> {
>> struct veth_priv *peer_priv, *priv = netdev_priv(dev);
>> @@ -591,14 +608,33 @@ static int veth_xdp_set(struct net_device *dev, struct bpf_prog *prog,
>> goto err;
>> }
>> }
>> +
>> + if (!old_prog) {
>> + peer->hw_features &= ~NETIF_F_GSO_SOFTWARE;
>> + peer->max_mtu = PAGE_SIZE - VETH_XDP_HEADROOM -
>> + peer->hard_header_len -
>> + SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
>> + if (peer->mtu > peer->max_mtu)
>> + dev_set_mtu(peer, peer->max_mtu);
>> + }
>> }
>>
>> if (old_prog) {
>> - if (!prog && dev->flags & IFF_UP)
>> - veth_disable_xdp(dev);
>> + if (!prog) {
>> + if (dev->flags & IFF_UP)
>> + veth_disable_xdp(dev);
>> +
>> + if (peer) {
>> + peer->hw_features |= NETIF_F_GSO_SOFTWARE;
>> + peer->max_mtu = ETH_MAX_MTU;
>> + }
>> + }
>> bpf_prog_put(old_prog);
>> }
>>
>> + if ((!!old_prog ^ !!prog) && peer)
>> + netdev_update_features(peer);
>> +
>> return 0;
>> err:
>> priv->_xdp_prog = old_prog;
>> @@ -643,6 +679,7 @@ static const struct net_device_ops veth_netdev_ops = {
>> .ndo_poll_controller = veth_poll_controller,
>> #endif
>> .ndo_get_iflink = veth_get_iflink,
>> + .ndo_fix_features = veth_fix_features,
>> .ndo_features_check = passthru_features_check,
>> .ndo_set_rx_headroom = veth_set_rx_headroom,
>> .ndo_bpf = veth_xdp,
--
Toshiaki Makita
^ permalink raw reply
* [PATCH bpf-next] bpf: btf: fix inconsistent IS_ERR and PTR_ERR
From: YueHaibing @ 2018-07-24 2:55 UTC (permalink / raw)
To: ast, daniel, quentin.monnet, jakub.kicinski, bhole_prashant_q7,
osk
Cc: linux-kernel, netdev, davem, YueHaibing
Fix inconsistent IS_ERR and PTR_ERR in get_btf,
the proper pointer to be passed as argument is '*btf'
This issue was detected with the help of Coccinelle.
Fixes: 2d3feca8c44f ("bpf: btf: print map dump and lookup with btf info")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
tools/bpf/bpftool/map.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
index 9c81918..0ee3ba4 100644
--- a/tools/bpf/bpftool/map.c
+++ b/tools/bpf/bpftool/map.c
@@ -230,7 +230,7 @@ static int get_btf(struct bpf_map_info *map_info, struct btf **btf)
*btf = btf__new((__u8 *)btf_info.btf, btf_info.btf_size, NULL);
if (IS_ERR(*btf)) {
- err = PTR_ERR(btf);
+ err = PTR_ERR(*btf);
*btf = NULL;
}
--
2.7.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox