* [PATCH 1/3] skbuff: use kvfree() to deallocate head
From: Jan Dakinevich @ 2019-08-22 10:48 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Cc: Denis Lunev, Konstantin Khorenko, jan.dakinevich@gmail.com,
Jan Dakinevich, David S. Miller, Alexey Kuznetsov (C),
Hideaki YOSHIFUJI, Pablo Neira Ayuso, Jozsef Kadlecsik,
Florian Westphal, Johannes Berg, David Ahern, Christian Brauner,
Jason A. Donenfeld, Jakub Kicinski, Stephen Hemminger,
Willem de Bruijn, Cong Wang, Simon Horman, John Hurley,
Paolo Abeni, Jesper Dangaard Brouer, Sebastian Andrzej Siewior,
Eric Dumazet, Li RongQing, Thomas Gleixner, Taehee Yoo,
Herbert Xu, Dmitry Safonov, netdev@vger.kernel.org,
netfilter-devel@vger.kernel.org, coreteam@netfilter.org
In-Reply-To: <1566470851-4694-1-git-send-email-jan.dakinevich@virtuozzo.com>
If skb buffer was allocated using vmalloc() it will make simple its
further deallocation.
Signed-off-by: Jan Dakinevich <jan.dakinevich@virtuozzo.com>
---
net/core/skbuff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 0338820..55eac01 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -588,7 +588,7 @@ static void skb_free_head(struct sk_buff *skb)
if (skb->head_frag)
skb_free_frag(head);
else
- kfree(head);
+ kvfree(head);
}
static void skb_release_data(struct sk_buff *skb)
--
2.1.4
^ permalink raw reply related
* [PATCH 0/3] rework netlink skb allocation
From: Jan Dakinevich @ 2019-08-22 10:48 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Cc: Denis Lunev, Konstantin Khorenko, jan.dakinevich@gmail.com,
Jan Dakinevich, David S. Miller, Alexey Kuznetsov (C),
Hideaki YOSHIFUJI, Pablo Neira Ayuso, Jozsef Kadlecsik,
Florian Westphal, Johannes Berg, David Ahern, Christian Brauner,
Stephen Hemminger, Jason A. Donenfeld, Jakub Kicinski,
Willem de Bruijn, Cong Wang, Simon Horman, John Hurley,
Paolo Abeni, Jesper Dangaard Brouer, Sebastian Andrzej Siewior,
Eric Dumazet, Li RongQing, Taehee Yoo, Patrick Talbert,
Herbert Xu, Thomas Gleixner, Dmitry Safonov,
netdev@vger.kernel.org, netfilter-devel@vger.kernel.org,
coreteam@netfilter.org
Currently, userspace is able to initiate costly high-order allocation in
kernel sending large broadcast netlink message, which is considered
undesirable. At the same time, unicast message are safe in this regard,
because they uses vmalloc-ed memory.
This series introduces changes, that allow broadcast messages to be
allocated with vmalloc() as well as unicast.
Jan Dakinevich (3):
skbuff: use kvfree() to deallocate head
netlink: always use vmapped memory for skb data
netlink: use generic skb_set_owner_r()
include/linux/netlink.h | 16 ----------------
net/core/skbuff.c | 2 +-
net/ipv4/fib_frontend.c | 2 +-
net/netfilter/nfnetlink.c | 2 +-
net/netlink/af_netlink.c | 39 +++++++--------------------------------
5 files changed, 10 insertions(+), 51 deletions(-)
--
2.1.4
^ permalink raw reply
* Re: [RFC bpf-next 4/5] iproute2: Allow compiling against libbpf
From: Toke Høiland-Jørgensen @ 2019-08-22 10:43 UTC (permalink / raw)
To: Daniel Borkmann, Stephen Hemminger, Alexei Starovoitov
Cc: Martin KaFai Lau, Song Liu, Yonghong Song, David Miller,
Jesper Dangaard Brouer, netdev, bpf, andrii.nakryiko
In-Reply-To: <9de36bbf-b70d-9320-c686-3033d0408276@iogearbox.net>
Daniel Borkmann <daniel@iogearbox.net> writes:
> On 8/20/19 1:47 PM, Toke Høiland-Jørgensen wrote:
>> This adds a configure check for libbpf and renames functions to allow
>> lib/bpf.c to be compiled with it present. This makes it possible to
>> port functionality piecemeal to use libbpf.
>>
>> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
>> ---
>> configure | 16 ++++++++++++++++
>> include/bpf_util.h | 6 +++---
>> ip/ipvrf.c | 4 ++--
>> lib/bpf.c | 33 +++++++++++++++++++--------------
>> 4 files changed, 40 insertions(+), 19 deletions(-)
>>
>> diff --git a/configure b/configure
>> index 45fcffb6..5a89ee9f 100755
>> --- a/configure
>> +++ b/configure
>> @@ -238,6 +238,19 @@ check_elf()
>> fi
>> }
>>
>> +check_libbpf()
>> +{
>> + if ${PKG_CONFIG} libbpf --exists; then
>> + echo "HAVE_LIBBPF:=y" >>$CONFIG
>> + echo "yes"
>> +
>> + echo 'CFLAGS += -DHAVE_LIBBPF' `${PKG_CONFIG} libbpf --cflags` >> $CONFIG
>> + echo 'LDLIBS += ' `${PKG_CONFIG} libbpf --libs` >>$CONFIG
>> + else
>> + echo "no"
>> + fi
>> +}
>> +
>> check_selinux()
>
> More of an implementation detail at this point in time, but want to
> make sure this doesn't get missed along the way: as discussed at
> bpfconf [0] best for iproute2 to handle libbpf support would be the
> same way of integration as pahole does, that is, to integrate it via
> submodule [1] to allow kernel and libbpf features to be in sync with
> iproute2 releases and therefore easily consume extensions we're adding
> to libbpf to aide iproute2 integration.
I can sorta see the point wrt keeping in sync with kernel features. But
how will this work with distros that package libbpf as a regular
library? Have you guys given up on regular library symbol versioning for
libbpf?
> [0] http://vger.kernel.org/bpfconf2019.html#session-4
Thanks for that link! Didn't manage to find any of the previous
discussions on iproute2 compatibility.
-Toke
^ permalink raw reply
* [PATCH] af_unix: utilize skb's fragment list for sending large datagrams
From: Jan Dakinevich @ 2019-08-22 10:38 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Cc: Denis Lunev, Konstantin Khorenko, Jan Dakinevich, David S. Miller,
Paolo Abeni, Al Viro, Jens Axboe, Hannes Reinecke, Karsten Graul,
Kyeongdon Kim, Thomas Gleixner, netdev@vger.kernel.org
When somebody tries to send big datagram, kernel makes an attempt to
avoid high-order allocation placing it into both: skb's data buffer
and skb's paged part (->frag).
However, paged part can not exceed MAX_SKB_FRAGS * PAGE_SIZE, and large
datagram causes increasing skb's data buffer. Thus, if any user-space
program sets send buffer (by calling setsockopt(SO_SNDBUF, ...)) to
maximum allowed size (wmem_max) it becomes able to cause any amount
of uncontrolled high-order kernel allocations.
To avoid this, do not pass more then SKB_MAX_ALLOC for skb's data
buffer and make use of fragment list of skb (->frag_list) in addition
to paged part for huge datagrams.
Signed-off-by: Jan Dakinevich <jan.dakinevich@virtuozzo.com>
---
net/unix/af_unix.c | 38 +++++++++++++++++++++++++++-----------
1 file changed, 27 insertions(+), 11 deletions(-)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 67e87db..0c13937 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1580,7 +1580,9 @@ static int unix_dgram_sendmsg(struct socket *sock, struct msghdr *msg,
struct sk_buff *skb;
long timeo;
struct scm_cookie scm;
- int data_len = 0;
+ unsigned long frag_len;
+ unsigned long paged_len;
+ unsigned long header_len;
int sk_locked;
wait_for_unix_gc();
@@ -1613,27 +1615,41 @@ static int unix_dgram_sendmsg(struct socket *sock, struct msghdr *msg,
if (len > sk->sk_sndbuf - 32)
goto out;
- if (len > SKB_MAX_ALLOC) {
- data_len = min_t(size_t,
- len - SKB_MAX_ALLOC,
- MAX_SKB_FRAGS * PAGE_SIZE);
- data_len = PAGE_ALIGN(data_len);
+ BUILD_BUG_ON(SKB_MAX_ALLOC < PAGE_SIZE);
- BUILD_BUG_ON(SKB_MAX_ALLOC < PAGE_SIZE);
- }
+ header_len = min(len, SKB_MAX_ALLOC);
+ paged_len = min(len - header_len, MAX_SKB_FRAGS * PAGE_SIZE);
+ frag_len = len - header_len - paged_len;
- skb = sock_alloc_send_pskb(sk, len - data_len, data_len,
+ skb = sock_alloc_send_pskb(sk, header_len, paged_len,
msg->msg_flags & MSG_DONTWAIT, &err,
PAGE_ALLOC_COSTLY_ORDER);
if (skb == NULL)
goto out;
+ while (frag_len) {
+ unsigned long size = min(SKB_MAX_ALLOC, frag_len);
+ struct sk_buff *frag;
+
+ frag = sock_alloc_send_pskb(sk, size, 0,
+ msg->msg_flags & MSG_DONTWAIT,
+ &err, 0);
+ if (!frag)
+ goto out_free;
+
+ skb_put(frag, size);
+ frag->next = skb_shinfo(skb)->frag_list;
+ skb_shinfo(skb)->frag_list = frag;
+
+ frag_len -= size;
+ }
+
err = unix_scm_to_skb(&scm, skb, true);
if (err < 0)
goto out_free;
- skb_put(skb, len - data_len);
- skb->data_len = data_len;
+ skb_put(skb, header_len);
+ skb->data_len = len - header_len;
skb->len = len;
err = skb_copy_datagram_from_iter(skb, 0, &msg->msg_iter, len);
if (err)
--
2.1.4
^ permalink raw reply related
* Re: [RFC bpf-next 0/5] Convert iproute2 to use libbpf (WIP)
From: Toke Høiland-Jørgensen @ 2019-08-22 10:38 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Alexei Starovoitov, Stephen Hemminger, Daniel Borkmann,
Alexei Starovoitov, Martin KaFai Lau, Song Liu, Yonghong Song,
David Miller, Jesper Dangaard Brouer, Networking, bpf
In-Reply-To: <CAEf4BzbR3gdn=82gCmSQ+=81222J0zza9z6JyYs=TkUY=WDXQw@mail.gmail.com>
Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
> On Wed, Aug 21, 2019 at 4:29 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>
>> Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:
>>
>> > On Tue, Aug 20, 2019 at 01:47:01PM +0200, Toke Høiland-Jørgensen wrote:
>> >> iproute2 uses its own bpf loader to load eBPF programs, which has
>> >> evolved separately from libbpf. Since we are now standardising on
>> >> libbpf, this becomes a problem as iproute2 is slowly accumulating
>> >> feature incompatibilities with libbpf-based loaders. In particular,
>> >> iproute2 has its own (expanded) version of the map definition struct,
>> >> which makes it difficult to write programs that can be loaded with both
>> >> custom loaders and iproute2.
>> >>
>> >> This series seeks to address this by converting iproute2 to using libbpf
>> >> for all its bpf needs. This version is an early proof-of-concept RFC, to
>> >> get some feedback on whether people think this is the right direction.
>> >>
>> >> What this series does is the following:
>> >>
>> >> - Updates the libbpf map definition struct to match that of iproute2
>> >> (patch 1).
>> >> - Adds functionality to libbpf to support automatic pinning of maps when
>> >> loading an eBPF program, while re-using pinned maps if they already
>> >> exist (patches 2-3).
>> >> - Modifies iproute2 to make it possible to compile it against libbpf
>> >> without affecting any existing functionality (patch 4).
>> >> - Changes the iproute2 eBPF loader to use libbpf for loading XDP
>> >> programs (patch 5).
>> >>
>> >>
>> >> As this is an early PoC, there are still a few missing pieces before
>> >> this can be merged. Including (but probably not limited to):
>> >>
>> >> - Consolidate the map definition struct in the bpf_helpers.h file in the
>> >> kernel tree. This contains a different, and incompatible, update to
>> >> the struct. Since the iproute2 version has actually been released for
>> >> use outside the kernel tree (and thus is subject to API stability
>> >> constraints), I think it makes the most sense to keep that, and port
>> >> the selftests to use it.
>> >
>> > It sounds like you're implying that existing libbpf format is not
>> > uapi.
>>
>> No, that's not what I meant... See below.
>>
>> > It is and we cannot break it.
>> > If patch 1 means breakage for existing pre-compiled .o that won't load
>> > with new libbpf then we cannot use this method.
>> > Recompiling .o with new libbpf definition of bpf_map_def isn't an option.
>> > libbpf has to be smart before/after and recognize both old and iproute2 format.
>>
>> The libbpf.h definition of struct bpf_map_def is compatible with the one
>> used in iproute2. In libbpf.h, the struct only contains five fields
>> (type, key_size, value_size, max_entries and flags), and iproute2 adds
>> another 4 (id, pinning, inner_id and inner_idx; these are the ones in
>> patch 1 in this series).
>>
>> The issue I was alluding to above is that the bpf_helpers.h file in the
>> kernel selftests directory *also* extends the bpf_map_def struct, and
>> adds two *different* fields (inner_map_idx and numa_mode). The former is
>> used to implement the same map-in-map definition functionality that
>> iproute2 has, but with different semantics. The latter is additional to
>> that, and I'm planning to add that to this series.
>>
>> Since bpf_helpers.h is *not* part of libbpf (yet), this will make it
>
> We should start considering it as if it was, so if we can avoid adding
> stuff that I'd need to untangle to move it into libbpf, I'd rather
> avoid it.
> We've already prepared this move by relicensing bpf_helpers.h. Moving
> it into libbpf itself is immediate next thing I'll do when I'm back.
Yeah, I figured that with the relicensing, bpf_helpers would probably be
making its way into libbpf soon. Which is why I wanted to start this
discussion before that: If we do move bpf_helpers as-is, that will put
us in the territory of full-on binary incompatibility. So the time to
discuss doing this in a compatible way is now, before any such move is
made.
-Toke
^ permalink raw reply
* Re: [PATCH] vsock: Fix a lockdep warning in __vsock_release()
From: Stefano Garzarella @ 2019-08-22 10:25 UTC (permalink / raw)
To: Dexuan Cui
Cc: jhansen@vmware.com, davem@davemloft.net, stefanha@redhat.com,
netdev@vger.kernel.org, Stephen Hemminger, Sasha Levin,
sashal@kernel.org, Haiyang Zhang, KY Srinivasan, Michael Kelley,
linux-hyperv@vger.kernel.org, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1566270830-28981-1-git-send-email-decui@microsoft.com>
On Tue, Aug 20, 2019 at 03:14:22AM +0000, Dexuan Cui wrote:
> Lockdep is unhappy if two locks from the same class are held.
>
> Fix the below warning by making __vsock_release() non-recursive -- this
> patch is kind of ugly, but it looks to me there is not a better way to
> deal with the problem here.
>
> ============================================
> WARNING: possible recursive locking detected
> 5.2.0+ #6 Not tainted
> --------------------------------------------
> a.out/1020 is trying to acquire lock:
> 0000000074731a98 (sk_lock-AF_VSOCK){+.+.}, at: hvs_release+0x10/0x120 [hv_sock]
>
> but task is already holding lock:
> 0000000014ff8397 (sk_lock-AF_VSOCK){+.+.}, at: __vsock_release+0x2e/0xf0 [vsock]
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
> CPU0
> ----
> lock(sk_lock-AF_VSOCK);
> lock(sk_lock-AF_VSOCK);
>
> *** DEADLOCK ***
>
> May be due to missing lock nesting notation
>
> 2 locks held by a.out/1020:
> #0: 00000000f8bceaa7 (&sb->s_type->i_mutex_key#10){+.+.}, at: __sock_release+0x2d/0xa0
> #1: 0000000014ff8397 (sk_lock-AF_VSOCK){+.+.}, at: __vsock_release+0x2e/0xf0 [vsock]
>
> stack backtrace:
> CPU: 7 PID: 1020 Comm: a.out Not tainted 5.2.0+ #6
> Call Trace:
> dump_stack+0x67/0x90
> __lock_acquire.cold.66+0x14d/0x1f8
> lock_acquire+0xb5/0x1c0
> lock_sock_nested+0x6d/0x90
> hvs_release+0x10/0x120 [hv_sock]
> __vsock_release+0x24/0xf0 [vsock]
> __vsock_release+0xa0/0xf0 [vsock]
> vsock_release+0x12/0x30 [vsock]
> __sock_release+0x37/0xa0
> sock_close+0x14/0x20
> __fput+0xc1/0x250
> task_work_run+0x98/0xc0
> do_exit+0x3dd/0xc60
> do_group_exit+0x47/0xc0
> get_signal+0x169/0xc60
> do_signal+0x30/0x710
> exit_to_usermode_loop+0x50/0xa0
> do_syscall_64+0x1fc/0x220
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
> ---
> net/vmw_vsock/af_vsock.c | 33 ++++++++++++++++++++++++++++++++-
> net/vmw_vsock/hyperv_transport.c | 2 +-
> 2 files changed, 33 insertions(+), 2 deletions(-)
>
> diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
> index ab47bf3..420f605 100644
> --- a/net/vmw_vsock/af_vsock.c
> +++ b/net/vmw_vsock/af_vsock.c
> @@ -638,6 +638,37 @@ struct sock *__vsock_create(struct net *net,
> }
> EXPORT_SYMBOL_GPL(__vsock_create);
>
> +static void __vsock_release2(struct sock *sk)
> +{
> + if (sk) {
> + struct sk_buff *skb;
> + struct vsock_sock *vsk;
> +
> + vsk = vsock_sk(sk);
> +
> + /* The release call is supposed to use lock_sock_nested()
> + * rather than lock_sock(), if a lock should be acquired.
> + */
> + transport->release(vsk);
> +
> + /* Use the nested version to avoid the warning
> + * "possible recursive locking detected".
> + */
> + lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
What about using lock_sock_nested() in the __vsock_release() without
define this new function?
> + sock_orphan(sk);
> + sk->sk_shutdown = SHUTDOWN_MASK;
> +
> + while ((skb = skb_dequeue(&sk->sk_receive_queue)))
> + kfree_skb(skb);
> +
> + /* This sk can not be a listener, so it's unnecessary
> + * to call vsock_dequeue_accept().
> + */
> + release_sock(sk);
> + sock_put(sk);
> + }
> +}
> +
> static void __vsock_release(struct sock *sk)
> {
> if (sk) {
> @@ -659,7 +690,7 @@ static void __vsock_release(struct sock *sk)
>
> /* Clean up any sockets that never were accepted. */
> while ((pending = vsock_dequeue_accept(sk)) != NULL) {
> - __vsock_release(pending);
> + __vsock_release2(pending);
> sock_put(pending);
> }
>
> diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
> index 9d864eb..4b126b2 100644
> --- a/net/vmw_vsock/hyperv_transport.c
> +++ b/net/vmw_vsock/hyperv_transport.c
> @@ -559,7 +559,7 @@ static void hvs_release(struct vsock_sock *vsk)
> struct sock *sk = sk_vsock(vsk);
> bool remove_sock;
>
> - lock_sock(sk);
> + lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
Should we update also other transports?
Thanks,
Stefano
^ permalink raw reply
* RE: Help needed - Kernel lockup while running ipsec
From: Vakul Garg @ 2019-08-22 10:23 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev@vger.kernel.org
In-Reply-To: <20190821161159.GA20113@breakpoint.cc>
> -----Original Message-----
> From: Florian Westphal <fw@strlen.de>
> Sent: Wednesday, August 21, 2019 9:42 PM
> To: Vakul Garg <vakul.garg@nxp.com>
> Cc: Florian Westphal <fw@strlen.de>; netdev@vger.kernel.org
> Subject: Re: Help needed - Kernel lockup while running ipsec
>
> Vakul Garg <vakul.garg@nxp.com> wrote:
> > > Policy refcount is decreasing properly on 4.19.
> > > Same should be on the latest kernel too.
> >
> > On kernel-4.14, I find dst_release() is getting called through
> xfrm_output_one().
> > However since dst->__refcnt gets decremented to '1', the
> > call_rcu(&dst->rcu_head, dst_destroy_rcu) is not invoked.
> >
> > On kernel-4.19, dst->__refcnt gets decremented to '0', hence things
> > fall in place and
> > dst_destroy_rcu() eventually executes.
> >
> > Any further help/pointers for kernel-4.14 would be deeply appreciated.
>
> Can you try getting rid of the pcpu dst cache?
>
> I had a look at 4.14-stable and it at least lacks 2950278d2d04ff531.
>
> I've attached an (untested) revert of the pcpu cache (its gone in 4.19 and
> onwards).
>
This patch fixed the refcnt issue. Many thanks for your help.
Would you send this patch for inclusion into 4.14-stable?
^ permalink raw reply
* Re: [PATCH bpf-next v4] libbpf: add xsk_ring_prod__nb_free() function
From: Eelco Chaudron @ 2019-08-22 10:20 UTC (permalink / raw)
To: Magnus Karlsson
Cc: Network Development, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Song Liu, Yonghong Song, Andrii Nakryiko
In-Reply-To: <CAJ8uoz1kQXgMUydktY3ci=8fjneUDW9B=qOGHzEQY1MvBThu8A@mail.gmail.com>
On 21 Aug 2019, at 16:53, Magnus Karlsson wrote:
> On Wed, Aug 21, 2019 at 4:14 PM Magnus Karlsson
> <magnus.karlsson@gmail.com> wrote:
>>
>> On Wed, Aug 21, 2019 at 3:46 PM Eelco Chaudron <echaudro@redhat.com>
>> wrote:
>>>
>>>
>>>
>>> On 21 Aug 2019, at 15:11, Magnus Karlsson wrote:
>>>
>>>> On Wed, Aug 14, 2019 at 3:51 PM Eelco Chaudron
>>>> <echaudro@redhat.com>
>>>> wrote:
>>>>>
>>>>> When an AF_XDP application received X packets, it does not mean X
>>>>> frames can be stuffed into the producer ring. To make it easier
>>>>> for
>>>>> AF_XDP applications this API allows them to check how many frames
>>>>> can
>>>>> be added into the ring.
>>>>>
>>>>> The patch below looks like a name change only, but the xsk_prod__
>>>>> prefix denotes that this API is exposed to be used by
>>>>> applications.
>>>>>
>>>>> Besides, if you set the nb value to the size of the ring, you will
>>>>> get the exact amount of slots available, at the cost of
>>>>> performance
>>>>> (you touch shared state for sure). nb is there to limit the
>>>>> touching of the shared state.
>>>>>
>>>>> Also the example xdpsock application has been modified to use this
>>>>> new API, so it's also able to process flows at a 1pps rate on veth
>>>>> interfaces.
>
> 1 pps! That is not that impressive ;-).
>
>>>> My apologies for the late reply and thank you for working on this.
>>>> So
>>>> what kind of performance difference do you see with your modified
>>>> xdpsock application on a regular NIC for txpush and l2fwd? If there
>>>> is
>>>> basically no difference or it is faster, we can go ahead and accept
>>>> this. But if the difference is large, we might consider to have two
>>>> versions of txpush and l2fwd as the regular NICs do not need this.
>>>> Or
>>>> we optimize your code so that it becomes as fast as the previous
>>>> version.
>>>
>>> For both operation modes, I ran 5 test with and without the changes
>>> applied using an iexgb connecting to a XENA tester. The throughput
>>> numbers were within the standard deviation, so no noticeable
>>> performance
>>> gain or drop.
>>
>> Sounds good, but let me take your patches for a run on something
>> faster, just to make sure we are CPU bound. Will get back.
>
> I ran some experiments and with two cores (app on one, softirq on
> another) there is no impact since the application core has cycles to
> spare. But if you run it on a single core the drop is 1- 2% for l2fwd.
> I think this is ok since your version is a better example and more
> correct. Just note that your patch did not apply cleanly to bpf-next,
> so please rebase it, resubmit and I will ack it.
Just sent out a v5 which is a tested rebase on the latest bpf-next.
<SNIP>
^ permalink raw reply
* Re: [PATCH v6 5/7] nfc: pn533: add UART phy driver
From: Claudiu.Beznea @ 2019-08-22 10:09 UTC (permalink / raw)
To: poeschel, gregkh, tglx, swinslow, allison, opensource, kstewart,
linux-kernel, netdev
Cc: johan
In-Reply-To: <20190820120345.22593-5-poeschel@lemonage.de>
Hi Lars,
On 20.08.2019 15:03, Lars Poeschel wrote:
> This adds the UART phy interface for the pn533 driver.
> The pn533 driver can be used through UART interface this way.
> It is implemented as a serdev device.
>
> Cc: Johan Hovold <johan@kernel.org>
> Signed-off-by: Lars Poeschel <poeschel@lemonage.de>
> ---
> Changes in v6:
> - Rebased the patch series on v5.3-rc5
>
> Changes in v5:
> - Use the splitted pn53x_common_init and pn53x_register_nfc
> and pn53x_common_clean and pn53x_unregister_nfc alike
>
> Changes in v4:
> - SPDX-License-Identifier: GPL-2.0+
> - Source code comments above refering items
> - Error check for serdev_device_write's
> - Change if (xxx == NULL) to if (!xxx)
> - Remove device name from a dev_err
> - move pn533_register in _probe a bit towards the end of _probe
> - make use of newly added dev_up / dev_down phy_ops
> - control send_wakeup variable from dev_up / dev_down
>
> Changes in v3:
> - depend on SERIAL_DEV_BUS in Kconfig
>
> Changes in v2:
> - switched from tty line discipline to serdev, resulting in many
> simplifications
> - SPDX License Identifier
>
> drivers/nfc/pn533/Kconfig | 11 ++
> drivers/nfc/pn533/Makefile | 2 +
> drivers/nfc/pn533/pn533.h | 8 +
> drivers/nfc/pn533/uart.c | 316 +++++++++++++++++++++++++++++++++++++
> 4 files changed, 337 insertions(+)
> create mode 100644 drivers/nfc/pn533/uart.c
>
> diff --git a/drivers/nfc/pn533/Kconfig b/drivers/nfc/pn533/Kconfig
> index f6d6b345ba0d..7fe1bbe26568 100644
> --- a/drivers/nfc/pn533/Kconfig
> +++ b/drivers/nfc/pn533/Kconfig
> @@ -26,3 +26,14 @@ config NFC_PN533_I2C
>
> If you choose to build a module, it'll be called pn533_i2c.
> Say N if unsure.
> +
> +config NFC_PN532_UART
> + tristate "NFC PN532 device support (UART)"
> + depends on SERIAL_DEV_BUS
> + select NFC_PN533
> + ---help---
> + This module adds support for the NXP pn532 UART interface.
> + Select this if your platform is using the UART bus.
> +
> + If you choose to build a module, it'll be called pn532_uart.
> + Say N if unsure.
> diff --git a/drivers/nfc/pn533/Makefile b/drivers/nfc/pn533/Makefile
> index 43c25b4f9466..b9648337576f 100644
> --- a/drivers/nfc/pn533/Makefile
> +++ b/drivers/nfc/pn533/Makefile
> @@ -4,7 +4,9 @@
> #
> pn533_usb-objs = usb.o
> pn533_i2c-objs = i2c.o
> +pn532_uart-objs = uart.o
>
> obj-$(CONFIG_NFC_PN533) += pn533.o
> obj-$(CONFIG_NFC_PN533_USB) += pn533_usb.o
> obj-$(CONFIG_NFC_PN533_I2C) += pn533_i2c.o
> +obj-$(CONFIG_NFC_PN532_UART) += pn532_uart.o
> diff --git a/drivers/nfc/pn533/pn533.h b/drivers/nfc/pn533/pn533.h
> index 510ddebbd896..6541088fad73 100644
> --- a/drivers/nfc/pn533/pn533.h
> +++ b/drivers/nfc/pn533/pn533.h
> @@ -43,6 +43,11 @@
>
> /* Preamble (1), SoPC (2), ACK Code (2), Postamble (1) */
> #define PN533_STD_FRAME_ACK_SIZE 6
> +/*
> + * Preamble (1), SoPC (2), Packet Length (1), Packet Length Checksum (1),
> + * Specific Application Level Error Code (1) , Postamble (1)
> + */
> +#define PN533_STD_ERROR_FRAME_SIZE 8
> #define PN533_STD_FRAME_CHECKSUM(f) (f->data[f->datalen])
> #define PN533_STD_FRAME_POSTAMBLE(f) (f->data[f->datalen + 1])
> /* Half start code (3), LEN (4) should be 0xffff for extended frame */
> @@ -84,6 +89,9 @@
> #define PN533_CMD_MI_MASK 0x40
> #define PN533_CMD_RET_SUCCESS 0x00
>
> +#define PN533_FRAME_DATALEN_ACK 0x00
> +#define PN533_FRAME_DATALEN_ERROR 0x01
> +#define PN533_FRAME_DATALEN_EXTENDED 0xFF
>
> enum pn533_protocol_type {
> PN533_PROTO_REQ_ACK_RESP = 0,
> diff --git a/drivers/nfc/pn533/uart.c b/drivers/nfc/pn533/uart.c
> new file mode 100644
> index 000000000000..f1cc2354a4fd
> --- /dev/null
> +++ b/drivers/nfc/pn533/uart.c
> @@ -0,0 +1,316 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Driver for NXP PN532 NFC Chip - UART transport layer
> + *
> + * Copyright (C) 2018 Lemonage Software GmbH
> + * Author: Lars Pöschel <poeschel@lemonage.de>
> + * All rights reserved.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/nfc.h>
> +#include <linux/netdevice.h>
> +#include <linux/of.h>
> +#include <linux/serdev.h>
> +#include "pn533.h"
> +
> +#define PN532_UART_SKB_BUFF_LEN (PN533_CMD_DATAEXCH_DATA_MAXLEN * 2)
> +
> +enum send_wakeup {
> + PN532_SEND_NO_WAKEUP = 0,
> + PN532_SEND_WAKEUP,
> + PN532_SEND_LAST_WAKEUP,
> +};
> +
> +
> +struct pn532_uart_phy {
> + struct serdev_device *serdev;
> + struct sk_buff *recv_skb;
> + struct pn533 *priv;
> + enum send_wakeup send_wakeup;
Could there be any concurrency issues w/ regards to accessing this
variable? I see it is accessed in pn532_uart_send_frame(), pn532_dev_up(),
pn532_dev_down() which may be called from the following wq:
INIT_WORK(&priv->mi_tm_rx_work, pn533_wq_tm_mi_recv);
INIT_WORK(&priv->mi_tm_tx_work, pn533_wq_tm_mi_send);
INIT_DELAYED_WORK(&priv->poll_work, pn533_wq_poll);
and from net/nfc/core.c via dev_up()/dev_down().
> + struct timer_list cmd_timeout;
> + struct sk_buff *cur_out_buf;
> +};
> +
> +static int pn532_uart_send_frame(struct pn533 *dev,
> + struct sk_buff *out)
> +{
> + /* wakeup sequence and dummy bytes for waiting time */
> + static const u8 wakeup[] = {
> + 0x55, 0x55, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
> + struct pn532_uart_phy *pn532 = dev->phy;
> + int err;
> +
> + print_hex_dump_debug("PN532_uart TX: ", DUMP_PREFIX_NONE, 16, 1,
> + out->data, out->len, false);
> +
> + pn532->cur_out_buf = out;
> + if (pn532->send_wakeup) {
> + err= serdev_device_write(pn532->serdev,
> + wakeup, sizeof(wakeup),
> + MAX_SCHEDULE_TIMEOUT);
> + if (err < 0)
> + return err;
> + }
> +
> + if (pn532->send_wakeup == PN532_SEND_LAST_WAKEUP) {
> + pn532->send_wakeup = PN532_SEND_NO_WAKEUP;
> + }
> +
> + err = serdev_device_write(pn532->serdev, out->data, out->len,
> + MAX_SCHEDULE_TIMEOUT);
> + if (err < 0)
> + return err;
> +
> + mod_timer(&pn532->cmd_timeout, HZ / 40 + jiffies);
> + return 0;
> +}
> +
> +static int pn532_uart_send_ack(struct pn533 *dev, gfp_t flags)
> +{
> + struct pn532_uart_phy *pn532 = dev->phy;
> + /* spec 7.1.1.3: Preamble, SoPC (2), ACK Code (2), Postamble */
> + static const u8 ack[PN533_STD_FRAME_ACK_SIZE] = {
> + 0x00, 0x00, 0xff, 0x00, 0xff, 0x00};
> + int err;
> +
> + err = serdev_device_write(pn532->serdev, ack, sizeof(ack),
> + MAX_SCHEDULE_TIMEOUT);
> + if (err < 0)
> + return err;
> +
> + return 0;
> +}
> +
> +static void pn532_uart_abort_cmd(struct pn533 *dev, gfp_t flags)
> +{
> + /* An ack will cancel the last issued command */
> + pn532_uart_send_ack(dev, flags);
> + /* schedule cmd_complete_work to finish current command execution */
> + pn533_recv_frame(dev, NULL, -ENOENT);
> +}
> +
> +static void pn532_dev_up(struct pn533 *dev)
> +{
> + struct pn532_uart_phy *pn532 = dev->phy;
> +
> + serdev_device_open(pn532->serdev);
> + pn532->send_wakeup = PN532_SEND_LAST_WAKEUP;
> +}
> +
> +static void pn532_dev_down(struct pn533 *dev)
> +{
> + struct pn532_uart_phy *pn532 = dev->phy;
> +
> + serdev_device_close(pn532->serdev);
> + pn532->send_wakeup = PN532_SEND_WAKEUP;
> +}
> +
> +static struct pn533_phy_ops uart_phy_ops = {
> + .send_frame = pn532_uart_send_frame,
> + .send_ack = pn532_uart_send_ack,
> + .abort_cmd = pn532_uart_abort_cmd,
> + .dev_up = pn532_dev_up,
> + .dev_down = pn532_dev_down,
> +};
> +
> +static void pn532_cmd_timeout(struct timer_list *t)
> +{
> + struct pn532_uart_phy *dev = from_timer(dev, t, cmd_timeout);
> +
> + pn532_uart_send_frame(dev->priv, dev->cur_out_buf);
> +}
> +
> +/*
> + * scans the buffer if it contains a pn532 frame. It is not checked if the
> + * frame is really valid. This is later done with pn533_rx_frame_is_valid.
> + * This is useful for malformed or errornous transmitted frames. Adjusts the
> + * bufferposition where the frame starts, since pn533_recv_frame expects a
> + * well formed frame.
> + */
> +static int pn532_uart_rx_is_frame(struct sk_buff *skb)
> +{
> + int i;
> + u16 frame_len;
> + struct pn533_std_frame *std;
> + struct pn533_ext_frame *ext;
> +
> + for (i = 0; i + PN533_STD_FRAME_ACK_SIZE <= skb->len; i++) {
> + std = (struct pn533_std_frame *)&skb->data[i];
> + /* search start code */
> + if (std->start_frame != cpu_to_be16(PN533_STD_FRAME_SOF))
> + continue;
> +
> + /* frame type */
> + switch (std->datalen) {
> + case PN533_FRAME_DATALEN_ACK:
> + if (std->datalen_checksum == 0xff) {
> + skb_pull(skb, i);
> + return 1;
> + }
> +
> + break;
> + case PN533_FRAME_DATALEN_ERROR:
> + if ((std->datalen_checksum == 0xff) &&
> + (skb->len >=
> + PN533_STD_ERROR_FRAME_SIZE)) {
> + skb_pull(skb, i);
> + return 1;
> + }
> +
> + break;
> + case PN533_FRAME_DATALEN_EXTENDED:
> + ext = (struct pn533_ext_frame *)&skb->data[i];
> + frame_len = ext->datalen;
> + if (skb->len >= frame_len +
> + sizeof(struct pn533_ext_frame) +
> + 2 /* CKS + Postamble */) {
> + skb_pull(skb, i);
> + return 1;
> + }
> +
> + break;
> + default: /* normal information frame */
> + frame_len = std->datalen;
> + if (skb->len >= frame_len +
> + sizeof(struct pn533_std_frame) +
> + 2 /* CKS + Postamble */) {
> + skb_pull(skb, i);
> + return 1;
> + }
> +
> + break;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int pn532_receive_buf(struct serdev_device *serdev,
> + const unsigned char *data, size_t count)
> +{
> + struct pn532_uart_phy *dev = serdev_device_get_drvdata(serdev);
> + size_t i;
> +
> + del_timer(&dev->cmd_timeout);
> + for (i = 0; i < count; i++) {
> + skb_put_u8(dev->recv_skb, *data++);
> + if (!pn532_uart_rx_is_frame(dev->recv_skb))
> + continue;
> +
> + pn533_recv_frame(dev->priv, dev->recv_skb, 0);
> + dev->recv_skb = alloc_skb(PN532_UART_SKB_BUFF_LEN, GFP_KERNEL);
> + if (!dev->recv_skb)
> + return 0;
> + }
> +
> + return i;
> +}
> +
> +static struct serdev_device_ops pn532_serdev_ops = {
> + .receive_buf = pn532_receive_buf,
> + .write_wakeup = serdev_device_write_wakeup,
> +};
> +
> +static const struct of_device_id pn532_uart_of_match[] = {
> + { .compatible = "nxp,pn532", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, pn532_uart_of_match);
> +
> +static int pn532_uart_probe(struct serdev_device *serdev)
> +{
> + struct pn532_uart_phy *pn532;
> + struct pn533 *priv;
> + int err;
> +
> + err = -ENOMEM;
> + pn532 = kzalloc(sizeof(*pn532), GFP_KERNEL);
> + if (!pn532)
> + goto err_exit;
> +
> + pn532->recv_skb = alloc_skb(PN532_UART_SKB_BUFF_LEN, GFP_KERNEL);
> + if (!pn532->recv_skb)
> + goto err_free;
> +
> + pn532->serdev = serdev;
> + serdev_device_set_drvdata(serdev, pn532);
> + serdev_device_set_client_ops(serdev, &pn532_serdev_ops);
> + err = serdev_device_open(serdev);
> + if (err) {
> + dev_err(&serdev->dev, "Unable to open device\n");
> + goto err_skb;
> + }
> +
> + err = serdev_device_set_baudrate(serdev, 115200);
> + if (err != 115200) {
> + err = -EINVAL;
> + goto err_serdev;
> + }
> +
> + serdev_device_set_flow_control(serdev, false);
> + pn532->send_wakeup = PN532_SEND_WAKEUP;
> + timer_setup(&pn532->cmd_timeout, pn532_cmd_timeout, 0);
> + priv = pn53x_common_init(PN533_DEVICE_PN532,
> + PN533_PROTO_REQ_ACK_RESP,
> + pn532, &uart_phy_ops, NULL,
> + &pn532->serdev->dev);
> + if (IS_ERR(priv)) {
> + err = PTR_ERR(priv);
> + goto err_serdev;
> + }
> +
> + pn532->priv = priv;
> + err = pn533_finalize_setup(pn532->priv);
> + if (err)
> + goto err_clean;
> +
> + serdev_device_close(serdev);
> + err = pn53x_register_nfc(priv, PN533_NO_TYPE_B_PROTOCOLS, &serdev->dev);
> + if (err) {
> + pn53x_common_clean(pn532->priv);
> + goto err_skb;
> + }
> +
> + return err;
> +
> +err_clean:
> + pn53x_common_clean(pn532->priv);
> +err_serdev:
> + serdev_device_close(serdev);
> +err_skb:
> + kfree_skb(pn532->recv_skb);
> +err_free:
> + kfree(pn532);
> +err_exit:
> + return err;
> +}
> +
> +static void pn532_uart_remove(struct serdev_device *serdev)
> +{
> + struct pn532_uart_phy *pn532 = serdev_device_get_drvdata(serdev);
> +
> + pn53x_unregister_nfc(pn532->priv);
> + serdev_device_close(serdev);
> + pn53x_common_clean(pn532->priv);
> + kfree_skb(pn532->recv_skb);
> + kfree(pn532);
> +}
> +
> +static struct serdev_device_driver pn532_uart_driver = {
> + .probe = pn532_uart_probe,
> + .remove = pn532_uart_remove,
> + .driver = {
> + .name = "pn532_uart",
> + .of_match_table = of_match_ptr(pn532_uart_of_match),
> + },
> +};
> +
> +module_serdev_device_driver(pn532_uart_driver);
> +
> +MODULE_AUTHOR("Lars Pöschel <poeschel@lemonage.de>");
> +MODULE_DESCRIPTION("PN532 UART driver");
> +MODULE_LICENSE("GPL");
>
^ permalink raw reply
* Re: [PATCH v6 4/7] nfc: pn533: Split pn533 init & nfc_register
From: Claudiu.Beznea @ 2019-08-22 10:08 UTC (permalink / raw)
To: poeschel, gregkh, allison, swinslow, tglx, kstewart, gustavo,
keescook, opensource, netdev, linux-kernel
Cc: johan
In-Reply-To: <20190820120345.22593-4-poeschel@lemonage.de>
On 20.08.2019 15:03, Lars Poeschel wrote:
> There is a problem in the initialisation and setup of the pn533: It
> registers with nfc too early. It could happen, that it finished
> registering with nfc and someone starts using it. But setup of the pn533
> is not yet finished. Bad or at least unintended things could happen.
> So I split out nfc registering (and unregistering) to seperate functions
> that have to be called late in probe then.
>
> Cc: Johan Hovold <johan@kernel.org>
> Signed-off-by: Lars Poeschel <poeschel@lemonage.de>
> ---
> Changes in v6:
> - Rebased the patch series on v5.3-rc5
>
> Changes in v5:
> - This patch is new in v5
>
> drivers/nfc/pn533/i2c.c | 17 +++++-----
> drivers/nfc/pn533/pn533.c | 66 ++++++++++++++++++++-------------------
> drivers/nfc/pn533/pn533.h | 11 ++++---
> drivers/nfc/pn533/usb.c | 12 +++++--
> 4 files changed, 59 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/nfc/pn533/i2c.c b/drivers/nfc/pn533/i2c.c
> index 1abd40398a5a..e9e5a1ec8857 100644
> --- a/drivers/nfc/pn533/i2c.c
> +++ b/drivers/nfc/pn533/i2c.c
> @@ -193,12 +193,10 @@ static int pn533_i2c_probe(struct i2c_client *client,
> phy->i2c_dev = client;
> i2c_set_clientdata(client, phy);
>
> - priv = pn533_register_device(PN533_DEVICE_PN532,
> - PN533_NO_TYPE_B_PROTOCOLS,
> + priv = pn53x_common_init(PN533_DEVICE_PN532,
> PN533_PROTO_REQ_ACK_RESP,
> phy, &i2c_phy_ops, NULL,
> - &phy->i2c_dev->dev,
> - &client->dev);
> + &phy->i2c_dev->dev);
>
> if (IS_ERR(priv)) {
> r = PTR_ERR(priv);
> @@ -220,13 +218,17 @@ static int pn533_i2c_probe(struct i2c_client *client,
> if (r)
> goto fn_setup_err;
>
> - return 0;
> + r = pn53x_register_nfc(priv, PN533_NO_TYPE_B_PROTOCOLS, &client->dev);
> + if (r)
> + goto fn_setup_err;
> +
> + return r;
>
> fn_setup_err:
> free_irq(client->irq, phy);
>
> irq_rqst_err:
> - pn533_unregister_device(phy->priv);
> + pn53x_common_clean(phy->priv);
>
> return r;
> }
> @@ -239,7 +241,8 @@ static int pn533_i2c_remove(struct i2c_client *client)
>
> free_irq(client->irq, phy);
>
> - pn533_unregister_device(phy->priv);
> + pn53x_unregister_nfc(phy->priv);
> + pn53x_common_clean(phy->priv);
>
> return 0;
> }
> diff --git a/drivers/nfc/pn533/pn533.c b/drivers/nfc/pn533/pn533.c
> index 64836c727aee..a8c756caa678 100644
> --- a/drivers/nfc/pn533/pn533.c
> +++ b/drivers/nfc/pn533/pn533.c
> @@ -2590,14 +2590,12 @@ int pn533_finalize_setup(struct pn533 *dev)
> }
> EXPORT_SYMBOL_GPL(pn533_finalize_setup);
>
> -struct pn533 *pn533_register_device(u32 device_type,
> - u32 protocols,
> +struct pn533 *pn53x_common_init(u32 device_type,
> enum pn533_protocol_type protocol_type,
> void *phy,
> struct pn533_phy_ops *phy_ops,
> struct pn533_frame_ops *fops,
> - struct device *dev,
> - struct device *parent)
> + struct device *dev)
> {
> struct pn533 *priv;
> int rc = -ENOMEM;
> @@ -2638,43 +2636,18 @@ struct pn533 *pn533_register_device(u32 device_type,
> skb_queue_head_init(&priv->fragment_skb);
>
> INIT_LIST_HEAD(&priv->cmd_queue);
> -
> - priv->nfc_dev = nfc_allocate_device(&pn533_nfc_ops, protocols,
> - priv->ops->tx_header_len +
> - PN533_CMD_DATAEXCH_HEAD_LEN,
> - priv->ops->tx_tail_len);
> - if (!priv->nfc_dev) {
> - rc = -ENOMEM;
> - goto destroy_wq;
> - }
> -
> - nfc_set_parent_dev(priv->nfc_dev, parent);
> - nfc_set_drvdata(priv->nfc_dev, priv);
> -
> - rc = nfc_register_device(priv->nfc_dev);
> - if (rc)
> - goto free_nfc_dev;
> -
> return priv;
>
> -free_nfc_dev:
> - nfc_free_device(priv->nfc_dev);
> -
> -destroy_wq:
> - destroy_workqueue(priv->wq);
> error:
> kfree(priv);
> return ERR_PTR(rc);
> }
> -EXPORT_SYMBOL_GPL(pn533_register_device);
> +EXPORT_SYMBOL_GPL(pn53x_common_init);
>
> -void pn533_unregister_device(struct pn533 *priv)
> +void pn53x_common_clean(struct pn533 *priv)
> {
> struct pn533_cmd *cmd, *n;
>
> - nfc_unregister_device(priv->nfc_dev);
> - nfc_free_device(priv->nfc_dev);
> -
> flush_delayed_work(&priv->poll_work);
> destroy_workqueue(priv->wq);
>
> @@ -2689,8 +2662,37 @@ void pn533_unregister_device(struct pn533 *priv)
>
> kfree(priv);
> }
> -EXPORT_SYMBOL_GPL(pn533_unregister_device);
> +EXPORT_SYMBOL_GPL(pn53x_common_clean);
> +
> +int pn53x_register_nfc(struct pn533 *priv, u32 protocols,
> + struct device *parent)
> +{
> + int rc = -ENOMEM;
No need to initialize rc here... or just return rc below.
> +
> + priv->nfc_dev = nfc_allocate_device(&pn533_nfc_ops, protocols,
> + priv->ops->tx_header_len +
> + PN533_CMD_DATAEXCH_HEAD_LEN,
> + priv->ops->tx_tail_len);
> + if (!priv->nfc_dev)
> + return -ENOMEM;
> +
> + nfc_set_parent_dev(priv->nfc_dev, parent);
> + nfc_set_drvdata(priv->nfc_dev, priv);
> +
> + rc = nfc_register_device(priv->nfc_dev);
> + if (rc)
> + nfc_free_device(priv->nfc_dev);
> +
> + return rc;
> +}
> +EXPORT_SYMBOL_GPL(pn53x_register_nfc);
>
> +void pn53x_unregister_nfc(struct pn533 *priv)
> +{
> + nfc_unregister_device(priv->nfc_dev);
> + nfc_free_device(priv->nfc_dev);
> +}
> +EXPORT_SYMBOL_GPL(pn53x_unregister_nfc);
>
> MODULE_AUTHOR("Lauro Ramos Venancio <lauro.venancio@openbossa.org>");
> MODULE_AUTHOR("Aloisio Almeida Jr <aloisio.almeida@openbossa.org>");
> diff --git a/drivers/nfc/pn533/pn533.h b/drivers/nfc/pn533/pn533.h
> index 570ee0a3e832..510ddebbd896 100644
> --- a/drivers/nfc/pn533/pn533.h
> +++ b/drivers/nfc/pn533/pn533.h
> @@ -219,18 +219,19 @@ struct pn533_phy_ops {
> };
>
>
> -struct pn533 *pn533_register_device(u32 device_type,
> - u32 protocols,
> +struct pn533 *pn53x_common_init(u32 device_type,
> enum pn533_protocol_type protocol_type,
> void *phy,
> struct pn533_phy_ops *phy_ops,
> struct pn533_frame_ops *fops,
> - struct device *dev,
> - struct device *parent);
> + struct device *dev);
>
> int pn533_finalize_setup(struct pn533 *dev);
> -void pn533_unregister_device(struct pn533 *priv);
> +void pn53x_common_clean(struct pn533 *priv);
> void pn533_recv_frame(struct pn533 *dev, struct sk_buff *skb, int status);
> +int pn53x_register_nfc(struct pn533 *priv, u32 protocols,
> + struct device *parent);
> +void pn53x_unregister_nfc(struct pn533 *priv);
>
> bool pn533_rx_frame_is_cmd_response(struct pn533 *dev, void *frame);
> bool pn533_rx_frame_is_ack(void *_frame);
> diff --git a/drivers/nfc/pn533/usb.c b/drivers/nfc/pn533/usb.c
> index c5289eaf17ee..a1c6a41944c6 100644
> --- a/drivers/nfc/pn533/usb.c
> +++ b/drivers/nfc/pn533/usb.c
> @@ -534,9 +534,9 @@ static int pn533_usb_probe(struct usb_interface *interface,
> goto error;
> }
>
> - priv = pn533_register_device(id->driver_info, protocols, protocol_type,
> + priv = pn53x_common_init(id->driver_info, protocol_type,
> phy, &usb_phy_ops, fops,
> - &phy->udev->dev, &interface->dev);
> + &phy->udev->dev);
>
> if (IS_ERR(priv)) {
> rc = PTR_ERR(priv);
> @@ -550,9 +550,14 @@ static int pn533_usb_probe(struct usb_interface *interface,
> goto error;
>
> usb_set_intfdata(interface, phy);
Above this instruction there is this code:
rc = pn533_finalize_setup(priv);
if (rc)
goto error;
Instead of "goto error;" you should have "goto err_clean;"
> + rc = pn53x_register_nfc(priv, protocols, &interface->dev);
> + if (rc)
> + goto err_clean;
>
> return 0;
>
> +err_clean:
> + pn53x_common_clean(priv);
> error:
> usb_free_urb(phy->in_urb);
> usb_free_urb(phy->out_urb);
> @@ -570,7 +575,8 @@ static void pn533_usb_disconnect(struct usb_interface *interface)
> if (!phy)
> return;
>
> - pn533_unregister_device(phy->priv);
> + pn53x_unregister_nfc(phy->priv);
> + pn53x_common_clean(phy->priv);
>
> usb_set_intfdata(interface, NULL);
>
>
^ permalink raw reply
* Re: [PATCH v2 10/11] vsock_test: skip read() in test_stream*close tests on a VMCI host
From: Stefano Garzarella @ 2019-08-22 10:08 UTC (permalink / raw)
To: Stefan Hajnoczi, Jorgen Hansen
Cc: netdev, kvm, Dexuan Cui, virtualization, David S. Miller,
linux-kernel
In-Reply-To: <20190820083203.GB9855@stefanha-x1.localdomain>
On Tue, Aug 20, 2019 at 09:32:03AM +0100, Stefan Hajnoczi wrote:
> On Thu, Aug 01, 2019 at 05:25:40PM +0200, Stefano Garzarella wrote:
> > When VMCI transport is used, if the guest closes a connection,
> > all data is gone and EOF is returned, so we should skip the read
> > of data written by the peer before closing the connection.
>
> All transports should aim for identical semantics. I think virtio-vsock
> should behave the same as VMCI since userspace applications should be
> transport-independent.
Yes, it is a good point!
>
> Let's view this as a vsock bug. Is it feasible to change the VMCI
> behavior so it's more like TCP sockets? If not, let's change the
> virtio-vsock behavior to be compatible with VMCI.
I'm not sure it is feasible to change the VMCI behavior. IIUC reading the
Jorgen's answer [1], this was a decision made during the implementation.
@Jorgen: please, can you confirm? or not :-)
If it is the case, I'll change virtio-vsock to the same behavior.
Thanks,
Stefano
[1] https://patchwork.ozlabs.org/cover/847998/#1831400
^ permalink raw reply
* RE: [PATCH v2 0/2] Simplify mtty driver and mdev core
From: Parav Pandit @ 2019-08-22 10:04 UTC (permalink / raw)
To: Jiri Pirko
Cc: Alex Williamson, Jiri Pirko, David S . Miller, Kirti Wankhede,
Cornelia Huck, kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
cjia, netdev@vger.kernel.org
In-Reply-To: <20190822095823.GB2276@nanopsycho.orion>
> -----Original Message-----
> From: Jiri Pirko <jiri@resnulli.us>
> Sent: Thursday, August 22, 2019 3:28 PM
> To: Parav Pandit <parav@mellanox.com>
> Cc: Alex Williamson <alex.williamson@redhat.com>; Jiri Pirko
> <jiri@mellanox.com>; David S . Miller <davem@davemloft.net>; Kirti
> Wankhede <kwankhede@nvidia.com>; Cornelia Huck <cohuck@redhat.com>;
> kvm@vger.kernel.org; linux-kernel@vger.kernel.org; cjia <cjia@nvidia.com>;
> netdev@vger.kernel.org
> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
>
> Thu, Aug 22, 2019 at 11:42:13AM CEST, parav@mellanox.com wrote:
> >
> >
> >> -----Original Message-----
> >> From: Jiri Pirko <jiri@resnulli.us>
> >> Sent: Thursday, August 22, 2019 2:59 PM
> >> To: Parav Pandit <parav@mellanox.com>
> >> Cc: Alex Williamson <alex.williamson@redhat.com>; Jiri Pirko
> >> <jiri@mellanox.com>; David S . Miller <davem@davemloft.net>; Kirti
> >> Wankhede <kwankhede@nvidia.com>; Cornelia Huck
> <cohuck@redhat.com>;
> >> kvm@vger.kernel.org; linux-kernel@vger.kernel.org; cjia
> >> <cjia@nvidia.com>; netdev@vger.kernel.org
> >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
> >>
> >> Wed, Aug 21, 2019 at 08:23:17AM CEST, parav@mellanox.com wrote:
> >> >
> >> >
> >> >> -----Original Message-----
> >> >> From: Alex Williamson <alex.williamson@redhat.com>
> >> >> Sent: Wednesday, August 21, 2019 10:56 AM
> >> >> To: Parav Pandit <parav@mellanox.com>
> >> >> Cc: Jiri Pirko <jiri@mellanox.com>; David S . Miller
> >> >> <davem@davemloft.net>; Kirti Wankhede <kwankhede@nvidia.com>;
> >> >> Cornelia Huck <cohuck@redhat.com>; kvm@vger.kernel.org;
> >> >> linux-kernel@vger.kernel.org; cjia <cjia@nvidia.com>;
> >> >> netdev@vger.kernel.org
> >> >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
> >> >>
> >> >> > > > > Just an example of the alias, not proposing how it's set.
> >> >> > > > > In fact, proposing that the user does not set it,
> >> >> > > > > mdev-core provides one
> >> >> > > automatically.
> >> >> > > > >
> >> >> > > > > > > Since there seems to be some prefix overhead, as I ask
> >> >> > > > > > > about above in how many characters we actually have to
> >> >> > > > > > > work with in IFNAMESZ, maybe we start with 8
> >> >> > > > > > > characters (matching your "index" namespace) and
> >> >> > > > > > > expand as necessary for
> >> disambiguation.
> >> >> > > > > > > If we can eliminate overhead in IFNAMESZ, let's start with 12.
> >> >> > > > > > > Thanks,
> >> >> > > > > > >
> >> >> > > > > > If user is going to choose the alias, why does it have
> >> >> > > > > > to be limited to
> >> >> sha1?
> >> >> > > > > > Or you just told it as an example?
> >> >> > > > > >
> >> >> > > > > > It can be an alpha-numeric string.
> >> >> > > > >
> >> >> > > > > No, I'm proposing a different solution where mdev-core
> >> >> > > > > creates an alias based on an abbreviated sha1. The user
> >> >> > > > > does not provide the
> >> >> alias.
> >> >> > > > >
> >> >> > > > > > Instead of mdev imposing number of characters on the
> >> >> > > > > > alias, it should be best
> >> >> > > > > left to the user.
> >> >> > > > > > Because in future if netdev improves on the naming
> >> >> > > > > > scheme, mdev will be
> >> >> > > > > limiting it, which is not right.
> >> >> > > > > > So not restricting alias size seems right to me.
> >> >> > > > > > User configuring mdev for networking devices in a given
> >> >> > > > > > kernel knows what
> >> >> > > > > user is doing.
> >> >> > > > > > So user can choose alias name size as it finds suitable.
> >> >> > > > >
> >> >> > > > > That's not what I'm proposing, please read again. Thanks,
> >> >> > > >
> >> >> > > > I understood your point. But mdev doesn't know how user is
> >> >> > > > going to use
> >> >> > > udev/systemd to name the netdev.
> >> >> > > > So even if mdev chose to pick 12 characters, it could result in
> collision.
> >> >> > > > Hence the proposal to provide the alias by the user, as user
> >> >> > > > know the best
> >> >> > > policy for its use case in the environment its using.
> >> >> > > > So 12 character sha1 method will still work by user.
> >> >> > >
> >> >> > > Haven't you already provided examples where certain drivers or
> >> >> > > subsystems have unique netdev prefixes? If mdev provides a
> >> >> > > unique alias within the subsystem, couldn't we simply define a
> >> >> > > netdev prefix for the mdev subsystem and avoid all other
> >> >> > > collisions? I'm not in favor of the user providing both a
> >> >> > > uuid and an alias/instance. Thanks,
> >> >> > >
> >> >> > For a given prefix, say ens2f0, can two UUID->sha1 first 9
> >> >> > characters have
> >> >> collision?
> >> >>
> >> >> I think it would be a mistake to waste so many chars on a prefix,
> >> >> but
> >> >> 9 characters of sha1 likely wouldn't have a collision before we
> >> >> have 10s of thousands of devices. Thanks,
> >> >>
> >> >> Alex
> >> >
> >> >Jiri, Dave,
> >> >Are you ok with it for devlink/netdev part?
> >> >Mdev core will create an alias from a UUID.
> >> >
> >> >This will be supplied during devlink port attr set such as,
> >> >
> >> >devlink_port_attrs_mdev_set(struct devlink_port *port, const char
> >> >*mdev_alias);
> >> >
> >> >This alias is used to generate representor netdev's phys_port_name.
> >> >This alias from the mdev device's sysfs will be used by the
> >> >udev/systemd to
> >> generate predicable netdev's name.
> >> >Example: enm<mdev_alias_first_12_chars>
> >>
> >> What happens in unlikely case of 2 UUIDs collide?
> >>
> >Since users sees two devices with same phys_port_name, user should destroy
> recently created mdev and recreate mdev with different UUID?
>
> Driver should make sure phys port name wont collide,
So when mdev creation is initiated, mdev core calculates the alias and if there is any other mdev with same alias exist, it returns -EEXIST error before progressing further.
This way user will get to know upfront in event of collision before the mdev device gets created.
How about that?
> in this case that it does
> not provide 2 same attrs for 2 different ports.
> Hmm, so the order of creation matters. That is not good.
>
> >>
> >> >I took Ethernet mdev as an example.
> >> >New prefix 'm' stands for mediated device.
> >> >Remaining 12 characters are first 12 chars of the mdev alias.
> >>
> >> Does this resolve the identification of devlink port representor?
> >Not sure if I understood your question correctly, attemping to answer below.
> >phys_port_name of devlink port is defined by the first 12 characters of mdev
> alias.
> >> I assume you want to use the same 12(or so) chars, don't you?
> >Mdev's netdev will also use the same mdev alias from the sysfs to rename
> netdev name from ethX to enm<mdev_alias>, where en=Etherenet, m=mdev.
> >
> >So yes, same 12 characters are use for mdev's netdev and mdev devlink port's
> phys_port_name.
> >
> >Is that what are you asking?
>
> Yes. Then you have 3 chars to handle the rest of the name (pci, pf)...
^ permalink raw reply
* [PATCH bpf-next v5 11/11] doc/af_xdp: include unaligned chunk case
From: Kevin Laatz @ 2019-08-22 1:44 UTC (permalink / raw)
To: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
jonathan.lemon, saeedm, maximmi, stephen
Cc: bruce.richardson, ciara.loftus, bpf, intel-wired-lan, Kevin Laatz
In-Reply-To: <20190822014427.49800-1-kevin.laatz@intel.com>
The addition of unaligned chunks mode, the documentation needs to be
updated to indicate that the incoming addr to the fill ring will only be
masked if the user application is run in the aligned chunk mode. This patch
also adds a line to explicitly indicate that the incoming addr will not be
masked if running the user application in the unaligned chunk mode.
Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
---
Documentation/networking/af_xdp.rst | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/Documentation/networking/af_xdp.rst b/Documentation/networking/af_xdp.rst
index eeedc2e826aa..83f7ae5fc045 100644
--- a/Documentation/networking/af_xdp.rst
+++ b/Documentation/networking/af_xdp.rst
@@ -153,10 +153,12 @@ an example, if the UMEM is 64k and each chunk is 4k, then the UMEM has
Frames passed to the kernel are used for the ingress path (RX rings).
-The user application produces UMEM addrs to this ring. Note that the
-kernel will mask the incoming addr. E.g. for a chunk size of 2k, the
-log2(2048) LSB of the addr will be masked off, meaning that 2048, 2050
-and 3000 refers to the same chunk.
+The user application produces UMEM addrs to this ring. Note that, if
+running the application with aligned chunk mode, the kernel will mask
+the incoming addr. E.g. for a chunk size of 2k, the log2(2048) LSB of
+the addr will be masked off, meaning that 2048, 2050 and 3000 refers
+to the same chunk. If the user application is run in the unaligned
+chunks mode, then the incoming addr will be left untouched.
UMEM Completion Ring
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next v5 10/11] samples/bpf: use hugepages in xdpsock app
From: Kevin Laatz @ 2019-08-22 1:44 UTC (permalink / raw)
To: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
jonathan.lemon, saeedm, maximmi, stephen
Cc: bruce.richardson, ciara.loftus, bpf, intel-wired-lan, Kevin Laatz
In-Reply-To: <20190822014427.49800-1-kevin.laatz@intel.com>
This patch modifies xdpsock to use mmap instead of posix_memalign. With
this change, we can use hugepages when running the application in unaligned
chunks mode. Using hugepages makes it more likely that we have physically
contiguous memory, which supports the unaligned chunk mode better.
Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
---
samples/bpf/xdpsock_user.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/samples/bpf/xdpsock_user.c b/samples/bpf/xdpsock_user.c
index dc3d50f8ed86..102eace22956 100644
--- a/samples/bpf/xdpsock_user.c
+++ b/samples/bpf/xdpsock_user.c
@@ -70,6 +70,7 @@ static int opt_interval = 1;
static u32 opt_xdp_bind_flags = XDP_USE_NEED_WAKEUP;
static u32 opt_umem_flags;
static int opt_unaligned_chunks;
+static int opt_mmap_flags;
static u32 opt_xdp_bind_flags;
static int opt_xsk_frame_size = XSK_UMEM__DEFAULT_FRAME_SIZE;
static int opt_timeout = 1000;
@@ -440,6 +441,7 @@ static void parse_command_line(int argc, char **argv)
case 'u':
opt_umem_flags |= XDP_UMEM_UNALIGNED_CHUNK_FLAG;
opt_unaligned_chunks = 1;
+ opt_mmap_flags = MAP_HUGETLB;
break;
case 'F':
opt_xdp_flags &= ~XDP_FLAGS_UPDATE_IF_NOEXIST;
@@ -742,11 +744,14 @@ int main(int argc, char **argv)
exit(EXIT_FAILURE);
}
- ret = posix_memalign(&bufs, getpagesize(), /* PAGE_SIZE aligned */
- NUM_FRAMES * opt_xsk_frame_size);
- if (ret)
- exit_with_error(ret);
-
+ /* Reserve memory for the umem. Use hugepages if unaligned chunk mode */
+ bufs = mmap(NULL, NUM_FRAMES * opt_xsk_frame_size,
+ PROT_READ | PROT_WRITE,
+ MAP_PRIVATE | MAP_ANONYMOUS | opt_mmap_flags, -1, 0);
+ if (bufs == MAP_FAILED) {
+ printf("ERROR: mmap failed\n");
+ exit(EXIT_FAILURE);
+ }
/* Create sockets... */
umem = xsk_configure_umem(bufs, NUM_FRAMES * opt_xsk_frame_size);
xsks[num_socks++] = xsk_configure_socket(umem);
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next v5 09/11] samples/bpf: add buffer recycling for unaligned chunks to xdpsock
From: Kevin Laatz @ 2019-08-22 1:44 UTC (permalink / raw)
To: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
jonathan.lemon, saeedm, maximmi, stephen
Cc: bruce.richardson, ciara.loftus, bpf, intel-wired-lan, Kevin Laatz
In-Reply-To: <20190822014427.49800-1-kevin.laatz@intel.com>
This patch adds buffer recycling support for unaligned buffers. Since we
don't mask the addr to 2k at umem_reg in unaligned mode, we need to make
sure we give back the correct (original) addr to the fill queue. We achieve
this using the new descriptor format and associated masks. The new format
uses the upper 16-bits for the offset and the lower 48-bits for the addr.
Since we have a field for the offset, we no longer need to modify the
actual address. As such, all we have to do to get back the original address
is mask for the lower 48 bits (i.e. strip the offset and we get the address
on it's own).
Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
v2:
- Removed unused defines
- Fix buffer recycling for unaligned case
- Remove --buf-size (--frame-size merged before this)
- Modifications to use the new descriptor format for buffer recycling
v5:
- Use new accessors for addr/offset instead of macros.
---
samples/bpf/xdpsock_user.c | 26 ++++++++++++++++----------
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/samples/bpf/xdpsock_user.c b/samples/bpf/xdpsock_user.c
index 7312eab4d201..dc3d50f8ed86 100644
--- a/samples/bpf/xdpsock_user.c
+++ b/samples/bpf/xdpsock_user.c
@@ -484,6 +484,7 @@ static void kick_tx(struct xsk_socket_info *xsk)
static inline void complete_tx_l2fwd(struct xsk_socket_info *xsk,
struct pollfd *fds)
{
+ struct xsk_umem_info *umem = xsk->umem;
u32 idx_cq = 0, idx_fq = 0;
unsigned int rcvd;
size_t ndescs;
@@ -498,24 +499,23 @@ static inline void complete_tx_l2fwd(struct xsk_socket_info *xsk,
xsk->outstanding_tx;
/* re-add completed Tx buffers */
- rcvd = xsk_ring_cons__peek(&xsk->umem->cq, ndescs, &idx_cq);
+ rcvd = xsk_ring_cons__peek(&umem->cq, ndescs, &idx_cq);
if (rcvd > 0) {
unsigned int i;
int ret;
- ret = xsk_ring_prod__reserve(&xsk->umem->fq, rcvd, &idx_fq);
+ ret = xsk_ring_prod__reserve(&umem->fq, rcvd, &idx_fq);
while (ret != rcvd) {
if (ret < 0)
exit_with_error(-ret);
- if (xsk_ring_prod__needs_wakeup(&xsk->umem->fq))
+ if (xsk_ring_prod__needs_wakeup(&umem->fq))
ret = poll(fds, num_socks, opt_timeout);
- ret = xsk_ring_prod__reserve(&xsk->umem->fq, rcvd,
- &idx_fq);
+ ret = xsk_ring_prod__reserve(&umem->fq, rcvd, &idx_fq);
}
+
for (i = 0; i < rcvd; i++)
- *xsk_ring_prod__fill_addr(&xsk->umem->fq, idx_fq++) =
- *xsk_ring_cons__comp_addr(&xsk->umem->cq,
- idx_cq++);
+ *xsk_ring_prod__fill_addr(&umem->fq, idx_fq++) =
+ *xsk_ring_cons__comp_addr(&umem->cq, idx_cq++);
xsk_ring_prod__submit(&xsk->umem->fq, rcvd);
xsk_ring_cons__release(&xsk->umem->cq, rcvd);
@@ -568,10 +568,13 @@ static void rx_drop(struct xsk_socket_info *xsk, struct pollfd *fds)
for (i = 0; i < rcvd; i++) {
u64 addr = xsk_ring_cons__rx_desc(&xsk->rx, idx_rx)->addr;
u32 len = xsk_ring_cons__rx_desc(&xsk->rx, idx_rx++)->len;
+ u64 orig = xsk_umem__extract_addr(addr);
+
+ addr = xsk_umem__add_offset_to_addr(addr);
char *pkt = xsk_umem__get_data(xsk->umem->buffer, addr);
hex_dump(pkt, len, addr);
- *xsk_ring_prod__fill_addr(&xsk->umem->fq, idx_fq++) = addr;
+ *xsk_ring_prod__fill_addr(&xsk->umem->fq, idx_fq++) = orig;
}
xsk_ring_prod__submit(&xsk->umem->fq, rcvd);
@@ -680,12 +683,15 @@ static void l2fwd(struct xsk_socket_info *xsk, struct pollfd *fds)
for (i = 0; i < rcvd; i++) {
u64 addr = xsk_ring_cons__rx_desc(&xsk->rx, idx_rx)->addr;
u32 len = xsk_ring_cons__rx_desc(&xsk->rx, idx_rx++)->len;
+ u64 orig = xsk_umem__extract_addr(addr);
+
+ addr = xsk_umem__add_offset_to_addr(addr);
char *pkt = xsk_umem__get_data(xsk->umem->buffer, addr);
swap_mac_addresses(pkt);
hex_dump(pkt, len, addr);
- xsk_ring_prod__tx_desc(&xsk->tx, idx_tx)->addr = addr;
+ xsk_ring_prod__tx_desc(&xsk->tx, idx_tx)->addr = orig;
xsk_ring_prod__tx_desc(&xsk->tx, idx_tx++)->len = len;
}
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next v5 08/11] samples/bpf: add unaligned chunks mode support to xdpsock
From: Kevin Laatz @ 2019-08-22 1:44 UTC (permalink / raw)
To: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
jonathan.lemon, saeedm, maximmi, stephen
Cc: bruce.richardson, ciara.loftus, bpf, intel-wired-lan, Kevin Laatz
In-Reply-To: <20190822014427.49800-1-kevin.laatz@intel.com>
This patch adds support for the unaligned chunks mode. The addition of the
unaligned chunks option will allow users to run the application with more
relaxed chunk placement in the XDP umem.
Unaligned chunks mode can be used with the '-u' or '--unaligned' command
line options.
Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
---
v4:
- updated help text for -f
- use new chunk flag define
---
samples/bpf/xdpsock_user.c | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/samples/bpf/xdpsock_user.c b/samples/bpf/xdpsock_user.c
index da84c760c094..7312eab4d201 100644
--- a/samples/bpf/xdpsock_user.c
+++ b/samples/bpf/xdpsock_user.c
@@ -68,6 +68,9 @@ static int opt_queue;
static int opt_poll;
static int opt_interval = 1;
static u32 opt_xdp_bind_flags = XDP_USE_NEED_WAKEUP;
+static u32 opt_umem_flags;
+static int opt_unaligned_chunks;
+static u32 opt_xdp_bind_flags;
static int opt_xsk_frame_size = XSK_UMEM__DEFAULT_FRAME_SIZE;
static int opt_timeout = 1000;
static bool opt_need_wakeup = true;
@@ -284,7 +287,9 @@ static struct xsk_umem_info *xsk_configure_umem(void *buffer, u64 size)
.comp_size = XSK_RING_CONS__DEFAULT_NUM_DESCS,
.frame_size = opt_xsk_frame_size,
.frame_headroom = XSK_UMEM__DEFAULT_FRAME_HEADROOM,
+ .flags = opt_umem_flags
};
+
int ret;
umem = calloc(1, sizeof(*umem));
@@ -293,6 +298,7 @@ static struct xsk_umem_info *xsk_configure_umem(void *buffer, u64 size)
ret = xsk_umem__create(&umem->umem, buffer, size, &umem->fq, &umem->cq,
&cfg);
+
if (ret)
exit_with_error(-ret);
@@ -355,6 +361,7 @@ static struct option long_options[] = {
{"copy", no_argument, 0, 'c'},
{"frame-size", required_argument, 0, 'f'},
{"no-need-wakeup", no_argument, 0, 'm'},
+ {"unaligned", no_argument, 0, 'u'},
{0, 0, 0, 0}
};
@@ -376,6 +383,8 @@ static void usage(const char *prog)
" -c, --copy Force copy mode.\n"
" -f, --frame-size=n Set the frame size (must be a power of two, default is %d).\n"
" -m, --no-need-wakeup Turn off use of driver need wakeup flag.\n"
+ " -f, --frame-size=n Set the frame size (must be a power of two in aligned mode, default is %d).\n"
+ " -u, --unaligned Enable unaligned chunk placement\n"
"\n";
fprintf(stderr, str, prog, XSK_UMEM__DEFAULT_FRAME_SIZE);
exit(EXIT_FAILURE);
@@ -388,8 +397,7 @@ static void parse_command_line(int argc, char **argv)
opterr = 0;
for (;;) {
-
- c = getopt_long(argc, argv, "Frtli:q:psSNn:czf:m",
+ c = getopt_long(argc, argv, "Frtli:q:psSNn:czf:mu",
long_options, &option_index);
if (c == -1)
break;
@@ -429,6 +437,10 @@ static void parse_command_line(int argc, char **argv)
case 'c':
opt_xdp_bind_flags |= XDP_COPY;
break;
+ case 'u':
+ opt_umem_flags |= XDP_UMEM_UNALIGNED_CHUNK_FLAG;
+ opt_unaligned_chunks = 1;
+ break;
case 'F':
opt_xdp_flags &= ~XDP_FLAGS_UPDATE_IF_NOEXIST;
break;
@@ -438,6 +450,7 @@ static void parse_command_line(int argc, char **argv)
opt_need_wakeup = false;
opt_xdp_bind_flags &= ~XDP_USE_NEED_WAKEUP;
break;
+
default:
usage(basename(argv[0]));
}
@@ -450,7 +463,8 @@ static void parse_command_line(int argc, char **argv)
usage(basename(argv[0]));
}
- if (opt_xsk_frame_size & (opt_xsk_frame_size - 1)) {
+ if ((opt_xsk_frame_size & (opt_xsk_frame_size - 1)) &&
+ !opt_unaligned_chunks) {
fprintf(stderr, "--frame-size=%d is not a power of two\n",
opt_xsk_frame_size);
usage(basename(argv[0]));
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next v5 07/11] libbpf: add flags to umem config
From: Kevin Laatz @ 2019-08-22 1:44 UTC (permalink / raw)
To: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
jonathan.lemon, saeedm, maximmi, stephen
Cc: bruce.richardson, ciara.loftus, bpf, intel-wired-lan, Kevin Laatz
In-Reply-To: <20190822014427.49800-1-kevin.laatz@intel.com>
This patch adds a 'flags' field to the umem_config and umem_reg structs.
This will allow for more options to be added for configuring umems.
The first use for the flags field is to add a flag for unaligned chunks
mode. These flags can either be user-provided or filled with a default.
Since we change the size of the xsk_umem_config struct, we need to version
the ABI. This patch includes the ABI versioning for xsk_umem__create. The
Makefile was also updated to handle multiple function versions in
check-abi.
Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
---
v2:
- Removed the headroom check from this patch. It has moved to the
previous patch.
v4:
- Modified chunk flag define.
v5:
- Added ABI versioning for xsk_umem__create().
- Updated Makefile to handle multiple function versions.
- Removed bitfields from xdp_umem_reg
- Fix conflicts after 'bpf-af-xdp-wakeup' was merged
---
tools/include/uapi/linux/if_xdp.h | 9 +++++++++
tools/lib/bpf/Makefile | 5 ++++-
tools/lib/bpf/libbpf.map | 1 +
tools/lib/bpf/xsk.c | 33 ++++++++++++++++++++++++++++---
tools/lib/bpf/xsk.h | 27 +++++++++++++++++++++++++
5 files changed, 71 insertions(+), 4 deletions(-)
diff --git a/tools/include/uapi/linux/if_xdp.h b/tools/include/uapi/linux/if_xdp.h
index 62b80d57b72a..be328c59389d 100644
--- a/tools/include/uapi/linux/if_xdp.h
+++ b/tools/include/uapi/linux/if_xdp.h
@@ -26,6 +26,9 @@
*/
#define XDP_USE_NEED_WAKEUP (1 << 3)
+/* Flags for xsk_umem_config flags */
+#define XDP_UMEM_UNALIGNED_CHUNK_FLAG (1 << 0)
+
struct sockaddr_xdp {
__u16 sxdp_family;
__u16 sxdp_flags;
@@ -66,6 +69,7 @@ struct xdp_umem_reg {
__u64 len; /* Length of packet data area */
__u32 chunk_size;
__u32 headroom;
+ __u32 flags;
};
struct xdp_statistics {
@@ -87,6 +91,11 @@ struct xdp_options {
#define XDP_UMEM_PGOFF_FILL_RING 0x100000000ULL
#define XDP_UMEM_PGOFF_COMPLETION_RING 0x180000000ULL
+/* Masks for unaligned chunks mode */
+#define XSK_UNALIGNED_BUF_OFFSET_SHIFT 48
+#define XSK_UNALIGNED_BUF_ADDR_MASK \
+ ((1ULL << XSK_UNALIGNED_BUF_OFFSET_SHIFT) - 1)
+
/* Rx/Tx descriptor */
struct xdp_desc {
__u64 addr;
diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
index 613acb93b144..c6f94cffe06e 100644
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@ -134,7 +134,9 @@ LIB_FILE := $(addprefix $(OUTPUT),$(LIB_FILE))
PC_FILE := $(addprefix $(OUTPUT),$(PC_FILE))
GLOBAL_SYM_COUNT = $(shell readelf -s --wide $(BPF_IN) | \
- awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {s++} END{print s}')
+ cut -d "@" -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | \
+ awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$8}' | \
+ sort -u | wc -l)
VERSIONED_SYM_COUNT = $(shell readelf -s --wide $(OUTPUT)libbpf.so | \
grep -Eo '[^ ]+@LIBBPF_' | cut -d@ -f1 | sort -u | wc -l)
@@ -201,6 +203,7 @@ check_abi: $(OUTPUT)libbpf.so
"Please make sure all LIBBPF_API symbols are" \
"versioned in $(VERSION_SCRIPT)." >&2; \
readelf -s --wide $(OUTPUT)libbpf-in.o | \
+ cut -d "@" -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | \
awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$8}'| \
sort -u > $(OUTPUT)libbpf_global_syms.tmp; \
readelf -s --wide $(OUTPUT)libbpf.so | \
diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
index 664ce8e7a60e..d04c7cb623ed 100644
--- a/tools/lib/bpf/libbpf.map
+++ b/tools/lib/bpf/libbpf.map
@@ -183,6 +183,7 @@ LIBBPF_0.0.4 {
perf_buffer__new;
perf_buffer__new_raw;
perf_buffer__poll;
+ xsk_umem__create;
} LIBBPF_0.0.3;
LIBBPF_0.0.5 {
diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c
index 12ad78510147..842c4fd55859 100644
--- a/tools/lib/bpf/xsk.c
+++ b/tools/lib/bpf/xsk.c
@@ -99,6 +99,7 @@ static void xsk_set_umem_config(struct xsk_umem_config *cfg,
cfg->comp_size = XSK_RING_CONS__DEFAULT_NUM_DESCS;
cfg->frame_size = XSK_UMEM__DEFAULT_FRAME_SIZE;
cfg->frame_headroom = XSK_UMEM__DEFAULT_FRAME_HEADROOM;
+ cfg->flags = XSK_UMEM__DEFAULT_FLAGS;
return;
}
@@ -106,6 +107,7 @@ static void xsk_set_umem_config(struct xsk_umem_config *cfg,
cfg->comp_size = usr_cfg->comp_size;
cfg->frame_size = usr_cfg->frame_size;
cfg->frame_headroom = usr_cfg->frame_headroom;
+ cfg->flags = usr_cfg->flags;
}
static int xsk_set_xdp_socket_config(struct xsk_socket_config *cfg,
@@ -132,9 +134,10 @@ static int xsk_set_xdp_socket_config(struct xsk_socket_config *cfg,
return 0;
}
-int xsk_umem__create(struct xsk_umem **umem_ptr, void *umem_area, __u64 size,
- struct xsk_ring_prod *fill, struct xsk_ring_cons *comp,
- const struct xsk_umem_config *usr_config)
+int xsk_umem__create_v0_0_4(struct xsk_umem **umem_ptr, void *umem_area,
+ __u64 size, struct xsk_ring_prod *fill,
+ struct xsk_ring_cons *comp,
+ const struct xsk_umem_config *usr_config)
{
struct xdp_mmap_offsets off;
struct xdp_umem_reg mr;
@@ -165,6 +168,7 @@ int xsk_umem__create(struct xsk_umem **umem_ptr, void *umem_area, __u64 size,
mr.len = size;
mr.chunk_size = umem->config.frame_size;
mr.headroom = umem->config.frame_headroom;
+ mr.flags = umem->config.flags;
err = setsockopt(umem->fd, SOL_XDP, XDP_UMEM_REG, &mr, sizeof(mr));
if (err) {
@@ -238,6 +242,29 @@ int xsk_umem__create(struct xsk_umem **umem_ptr, void *umem_area, __u64 size,
return err;
}
+struct xsk_umem_config_v1 {
+ __u32 fill_size;
+ __u32 comp_size;
+ __u32 frame_size;
+ __u32 frame_headroom;
+};
+
+int xsk_umem__create_v0_0_2(struct xsk_umem **umem_ptr, void *umem_area,
+ __u64 size, struct xsk_ring_prod *fill,
+ struct xsk_ring_cons *comp,
+ const struct xsk_umem_config *usr_config)
+{
+ struct xsk_umem_config config;
+
+ memcpy(&config, usr_config, sizeof(struct xsk_umem_config_v1));
+ config.flags = 0;
+
+ return xsk_umem__create_v0_0_4(umem_ptr, umem_area, size, fill, comp,
+ &config);
+}
+asm(".symver xsk_umem__create_v0_0_2, xsk_umem__create@LIBBPF_0.0.2");
+asm(".symver xsk_umem__create_v0_0_4, xsk_umem__create@@LIBBPF_0.0.4");
+
static int xsk_load_xdp_prog(struct xsk_socket *xsk)
{
static const int log_buf_size = 16 * 1024;
diff --git a/tools/lib/bpf/xsk.h b/tools/lib/bpf/xsk.h
index aa1d6122b7db..584f6820a639 100644
--- a/tools/lib/bpf/xsk.h
+++ b/tools/lib/bpf/xsk.h
@@ -168,6 +168,21 @@ static inline void *xsk_umem__get_data(void *umem_area, __u64 addr)
return &((char *)umem_area)[addr];
}
+static inline __u64 xsk_umem__extract_addr(__u64 addr)
+{
+ return addr & XSK_UNALIGNED_BUF_ADDR_MASK;
+}
+
+static inline __u64 xsk_umem__extract_offset(__u64 addr)
+{
+ return addr >> XSK_UNALIGNED_BUF_OFFSET_SHIFT;
+}
+
+static inline __u64 xsk_umem__add_offset_to_addr(__u64 addr)
+{
+ return xsk_umem__extract_addr(addr) + xsk_umem__extract_offset(addr);
+}
+
LIBBPF_API int xsk_umem__fd(const struct xsk_umem *umem);
LIBBPF_API int xsk_socket__fd(const struct xsk_socket *xsk);
@@ -176,12 +191,14 @@ LIBBPF_API int xsk_socket__fd(const struct xsk_socket *xsk);
#define XSK_UMEM__DEFAULT_FRAME_SHIFT 12 /* 4096 bytes */
#define XSK_UMEM__DEFAULT_FRAME_SIZE (1 << XSK_UMEM__DEFAULT_FRAME_SHIFT)
#define XSK_UMEM__DEFAULT_FRAME_HEADROOM 0
+#define XSK_UMEM__DEFAULT_FLAGS 0
struct xsk_umem_config {
__u32 fill_size;
__u32 comp_size;
__u32 frame_size;
__u32 frame_headroom;
+ __u32 flags;
};
/* Flags for the libbpf_flags field. */
@@ -201,6 +218,16 @@ LIBBPF_API int xsk_umem__create(struct xsk_umem **umem,
struct xsk_ring_prod *fill,
struct xsk_ring_cons *comp,
const struct xsk_umem_config *config);
+LIBBPF_API int xsk_umem__create_v0_0_2(struct xsk_umem **umem,
+ void *umem_area, __u64 size,
+ struct xsk_ring_prod *fill,
+ struct xsk_ring_cons *comp,
+ const struct xsk_umem_config *config);
+LIBBPF_API int xsk_umem__create_v0_0_4(struct xsk_umem **umem,
+ void *umem_area, __u64 size,
+ struct xsk_ring_prod *fill,
+ struct xsk_ring_cons *comp,
+ const struct xsk_umem_config *config);
LIBBPF_API int xsk_socket__create(struct xsk_socket **xsk,
const char *ifname, __u32 queue_id,
struct xsk_umem *umem,
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next v5 06/11] mlx5e: modify driver for handling offsets
From: Kevin Laatz @ 2019-08-22 1:44 UTC (permalink / raw)
To: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
jonathan.lemon, saeedm, maximmi, stephen
Cc: bruce.richardson, ciara.loftus, bpf, intel-wired-lan, Kevin Laatz
In-Reply-To: <20190822014427.49800-1-kevin.laatz@intel.com>
With the addition of the unaligned chunks option, we need to make sure we
handle the offsets accordingly based on the mode we are currently running
in. This patch modifies the driver to appropriately mask the address for
each case.
Note: This patch only adds support for the new offset handling. An
additional patch that enables the unaligned chunks feature (makes mlx5e
accept arbitrary frame sizes) will be added later and will apply on top
of this patch.
Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
---
v3:
- Use new helper function to handle offset
v4:
- fixed headroom addition to handle. Using xsk_umem_adjust_headroom()
now.
v5:
- Fixed typo: handle_offset -> adjust_offset
---
drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c | 8 ++++++--
drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.c | 3 ++-
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c b/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
index 1ed5c33e022f..f049e0ac308a 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
@@ -122,6 +122,7 @@ bool mlx5e_xdp_handle(struct mlx5e_rq *rq, struct mlx5e_dma_info *di,
void *va, u16 *rx_headroom, u32 *len, bool xsk)
{
struct bpf_prog *prog = READ_ONCE(rq->xdp_prog);
+ struct xdp_umem *umem = rq->umem;
struct xdp_buff xdp;
u32 act;
int err;
@@ -138,8 +139,11 @@ bool mlx5e_xdp_handle(struct mlx5e_rq *rq, struct mlx5e_dma_info *di,
xdp.rxq = &rq->xdp_rxq;
act = bpf_prog_run_xdp(prog, &xdp);
- if (xsk)
- xdp.handle += xdp.data - xdp.data_hard_start;
+ if (xsk) {
+ u64 off = xdp.data - xdp.data_hard_start;
+
+ xdp.handle = xsk_umem_adjust_offset(umem, xdp.handle, off);
+ }
switch (act) {
case XDP_PASS:
*rx_headroom = xdp.data - xdp.data_hard_start;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.c
index 6a55573ec8f2..7c49a66d28c9 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.c
@@ -24,7 +24,8 @@ int mlx5e_xsk_page_alloc_umem(struct mlx5e_rq *rq,
if (!xsk_umem_peek_addr_rq(umem, &handle))
return -ENOMEM;
- dma_info->xsk.handle = handle + rq->buff.umem_headroom;
+ dma_info->xsk.handle = xsk_umem_adjust_offset(umem, handle,
+ rq->buff.umem_headroom);
dma_info->xsk.data = xdp_umem_get_data(umem, dma_info->xsk.handle);
/* No need to add headroom to the DMA address. In striding RQ case, we
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next v5 05/11] ixgbe: modify driver for handling offsets
From: Kevin Laatz @ 2019-08-22 1:44 UTC (permalink / raw)
To: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
jonathan.lemon, saeedm, maximmi, stephen
Cc: bruce.richardson, ciara.loftus, bpf, intel-wired-lan, Kevin Laatz
In-Reply-To: <20190822014427.49800-1-kevin.laatz@intel.com>
With the addition of the unaligned chunks option, we need to make sure we
handle the offsets accordingly based on the mode we are currently running
in. This patch modifies the driver to appropriately mask the address for
each case.
Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
---
v3:
- Use new helper function to handle offset
---
drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
index e1f743470ae9..17061c799f72 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
@@ -143,7 +143,9 @@ static int ixgbe_run_xdp_zc(struct ixgbe_adapter *adapter,
struct ixgbe_ring *rx_ring,
struct xdp_buff *xdp)
{
+ struct xdp_umem *umem = rx_ring->xsk_umem;
int err, result = IXGBE_XDP_PASS;
+ u64 offset = umem->headroom;
struct bpf_prog *xdp_prog;
struct xdp_frame *xdpf;
u32 act;
@@ -151,7 +153,10 @@ static int ixgbe_run_xdp_zc(struct ixgbe_adapter *adapter,
rcu_read_lock();
xdp_prog = READ_ONCE(rx_ring->xdp_prog);
act = bpf_prog_run_xdp(xdp_prog, xdp);
- xdp->handle += xdp->data - xdp->data_hard_start;
+ offset += xdp->data - xdp->data_hard_start;
+
+ xdp->handle = xsk_umem_adjust_offset(umem, xdp->handle, offset);
+
switch (act) {
case XDP_PASS:
break;
@@ -243,7 +248,7 @@ void ixgbe_zca_free(struct zero_copy_allocator *alloc, unsigned long handle)
bi->addr = xdp_umem_get_data(rx_ring->xsk_umem, handle);
bi->addr += hr;
- bi->handle = (u64)handle + rx_ring->xsk_umem->headroom;
+ bi->handle = (u64)handle;
}
static bool ixgbe_alloc_buffer_zc(struct ixgbe_ring *rx_ring,
@@ -269,7 +274,7 @@ static bool ixgbe_alloc_buffer_zc(struct ixgbe_ring *rx_ring,
bi->addr = xdp_umem_get_data(umem, handle);
bi->addr += hr;
- bi->handle = handle + umem->headroom;
+ bi->handle = handle;
xsk_umem_discard_addr(umem);
return true;
@@ -296,7 +301,7 @@ static bool ixgbe_alloc_buffer_slow_zc(struct ixgbe_ring *rx_ring,
bi->addr = xdp_umem_get_data(umem, handle);
bi->addr += hr;
- bi->handle = handle + umem->headroom;
+ bi->handle = handle;
xsk_umem_discard_addr_rq(umem);
return true;
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next v5 04/11] i40e: modify driver for handling offsets
From: Kevin Laatz @ 2019-08-22 1:44 UTC (permalink / raw)
To: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
jonathan.lemon, saeedm, maximmi, stephen
Cc: bruce.richardson, ciara.loftus, bpf, intel-wired-lan, Kevin Laatz
In-Reply-To: <20190822014427.49800-1-kevin.laatz@intel.com>
With the addition of the unaligned chunks option, we need to make sure we
handle the offsets accordingly based on the mode we are currently running
in. This patch modifies the driver to appropriately mask the address for
each case.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
---
v3:
- Use new helper function for handling the offset
---
drivers/net/ethernet/intel/i40e/i40e_xsk.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_xsk.c b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
index 2d6e82f72f48..eaca6162a6e6 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_xsk.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
@@ -190,7 +190,9 @@ int i40e_xsk_umem_setup(struct i40e_vsi *vsi, struct xdp_umem *umem,
**/
static int i40e_run_xdp_zc(struct i40e_ring *rx_ring, struct xdp_buff *xdp)
{
+ struct xdp_umem *umem = rx_ring->xsk_umem;
int err, result = I40E_XDP_PASS;
+ u64 offset = umem->headroom;
struct i40e_ring *xdp_ring;
struct bpf_prog *xdp_prog;
u32 act;
@@ -201,7 +203,10 @@ static int i40e_run_xdp_zc(struct i40e_ring *rx_ring, struct xdp_buff *xdp)
*/
xdp_prog = READ_ONCE(rx_ring->xdp_prog);
act = bpf_prog_run_xdp(xdp_prog, xdp);
- xdp->handle += xdp->data - xdp->data_hard_start;
+ offset += xdp->data - xdp->data_hard_start;
+
+ xdp->handle = xsk_umem_adjust_offset(umem, xdp->handle, offset);
+
switch (act) {
case XDP_PASS:
break;
@@ -262,7 +267,7 @@ static bool i40e_alloc_buffer_zc(struct i40e_ring *rx_ring,
bi->addr = xdp_umem_get_data(umem, handle);
bi->addr += hr;
- bi->handle = handle + umem->headroom;
+ bi->handle = handle;
xsk_umem_discard_addr(umem);
return true;
@@ -299,7 +304,7 @@ static bool i40e_alloc_buffer_slow_zc(struct i40e_ring *rx_ring,
bi->addr = xdp_umem_get_data(umem, handle);
bi->addr += hr;
- bi->handle = handle + umem->headroom;
+ bi->handle = handle;
xsk_umem_discard_addr_rq(umem);
return true;
@@ -464,7 +469,7 @@ void i40e_zca_free(struct zero_copy_allocator *alloc, unsigned long handle)
bi->addr = xdp_umem_get_data(rx_ring->xsk_umem, handle);
bi->addr += hr;
- bi->handle = (u64)handle + rx_ring->xsk_umem->headroom;
+ bi->handle = (u64)handle;
}
/**
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next v5 03/11] xsk: add support to allow unaligned chunk placement
From: Kevin Laatz @ 2019-08-22 1:44 UTC (permalink / raw)
To: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
jonathan.lemon, saeedm, maximmi, stephen
Cc: bruce.richardson, ciara.loftus, bpf, intel-wired-lan, Kevin Laatz
In-Reply-To: <20190822014427.49800-1-kevin.laatz@intel.com>
Currently, addresses are chunk size aligned. This means, we are very
restricted in terms of where we can place chunk within the umem. For
example, if we have a chunk size of 2k, then our chunks can only be placed
at 0,2k,4k,6k,8k... and so on (ie. every 2k starting from 0).
This patch introduces the ability to use unaligned chunks. With these
changes, we are no longer bound to having to place chunks at a 2k (or
whatever your chunk size is) interval. Since we are no longer dealing with
aligned chunks, they can now cross page boundaries. Checks for page
contiguity have been added in order to keep track of which pages are
followed by a physically contiguous page.
Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
v2:
- Add checks for the flags coming from userspace
- Fix how we get chunk_size in xsk_diag.c
- Add defines for masking the new descriptor format
- Modified the rx functions to use new descriptor format
- Modified the tx functions to use new descriptor format
v3:
- Add helper function to do address/offset masking/addition
v4:
- fixed page_start calculation in __xsk_rcv_memcpy().
- move offset handling to the xdp_umem_get_* functions
- modified the len field in xdp_umem_reg struct. We now use 16 bits from
this for the flags field.
- removed next_pg_contig field from xdp_umem_page struct. Using low 12
bits of addr to store flags instead.
- other minor changes based on review comments
v5:
- Added accessors for getting addr and offset
- Added helper function to add offset to addr
- Fixed offset handling in xsk_rcv
- Removed bitfields from xdp_umem_reg
- Added struct size checking for xdp_umem_reg in xsk_setsockopt to handle
different versions of the struct.
- fix conflicts after 'bpf-af-xdp-wakeup' was merged.
---
include/net/xdp_sock.h | 75 +++++++++++++++++++++++++++--
include/uapi/linux/if_xdp.h | 9 ++++
net/xdp/xdp_umem.c | 19 ++++++--
net/xdp/xsk.c | 96 +++++++++++++++++++++++++++++--------
net/xdp/xsk_diag.c | 2 +-
net/xdp/xsk_queue.h | 68 ++++++++++++++++++++++----
6 files changed, 232 insertions(+), 37 deletions(-)
diff --git a/include/net/xdp_sock.h b/include/net/xdp_sock.h
index f023b9940d64..c9398ce7960f 100644
--- a/include/net/xdp_sock.h
+++ b/include/net/xdp_sock.h
@@ -16,6 +16,13 @@
struct net_device;
struct xsk_queue;
+/* Masks for xdp_umem_page flags.
+ * The low 12-bits of the addr will be 0 since this is the page address, so we
+ * can use them for flags.
+ */
+#define XSK_NEXT_PG_CONTIG_SHIFT 0
+#define XSK_NEXT_PG_CONTIG_MASK (1ULL << XSK_NEXT_PG_CONTIG_SHIFT)
+
struct xdp_umem_page {
void *addr;
dma_addr_t dma;
@@ -27,8 +34,12 @@ struct xdp_umem_fq_reuse {
u64 handles[];
};
-/* Flags for the umem flags field. */
-#define XDP_UMEM_USES_NEED_WAKEUP (1 << 0)
+/* Flags for the umem flags field.
+ *
+ * The NEED_WAKEUP flag is 1 due to the reuse of the flags field for public
+ * flags. See inlude/uapi/include/linux/if_xdp.h.
+ */
+#define XDP_UMEM_USES_NEED_WAKEUP (1 << 1)
struct xdp_umem {
struct xsk_queue *fq;
@@ -124,14 +135,36 @@ void xsk_map_try_sock_delete(struct xsk_map *map, struct xdp_sock *xs,
int xsk_map_inc(struct xsk_map *map);
void xsk_map_put(struct xsk_map *map);
+static inline u64 xsk_umem_extract_addr(u64 addr)
+{
+ return addr & XSK_UNALIGNED_BUF_ADDR_MASK;
+}
+
+static inline u64 xsk_umem_extract_offset(u64 addr)
+{
+ return addr >> XSK_UNALIGNED_BUF_OFFSET_SHIFT;
+}
+
+static inline u64 xsk_umem_add_offset_to_addr(u64 addr)
+{
+ return xsk_umem_extract_addr(addr) + xsk_umem_extract_offset(addr);
+}
+
static inline char *xdp_umem_get_data(struct xdp_umem *umem, u64 addr)
{
- return umem->pages[addr >> PAGE_SHIFT].addr + (addr & (PAGE_SIZE - 1));
+ unsigned long page_addr;
+
+ addr = xsk_umem_add_offset_to_addr(addr);
+ page_addr = (unsigned long)umem->pages[addr >> PAGE_SHIFT].addr;
+
+ return (char *)(page_addr & PAGE_MASK) + (addr & ~PAGE_MASK);
}
static inline dma_addr_t xdp_umem_get_dma(struct xdp_umem *umem, u64 addr)
{
- return umem->pages[addr >> PAGE_SHIFT].dma + (addr & (PAGE_SIZE - 1));
+ addr = xsk_umem_add_offset_to_addr(addr);
+
+ return umem->pages[addr >> PAGE_SHIFT].dma + (addr & ~PAGE_MASK);
}
/* Reuse-queue aware version of FILL queue helpers */
@@ -172,6 +205,19 @@ static inline void xsk_umem_fq_reuse(struct xdp_umem *umem, u64 addr)
rq->handles[rq->length++] = addr;
}
+
+/* Handle the offset appropriately depending on aligned or unaligned mode.
+ * For unaligned mode, we store the offset in the upper 16-bits of the address.
+ * For aligned mode, we simply add the offset to the address.
+ */
+static inline u64 xsk_umem_adjust_offset(struct xdp_umem *umem, u64 address,
+ u64 offset)
+{
+ if (umem->flags & XDP_UMEM_UNALIGNED_CHUNK_FLAG)
+ return address + (offset << XSK_UNALIGNED_BUF_OFFSET_SHIFT);
+ else
+ return address + offset;
+}
#else
static inline int xsk_generic_rcv(struct xdp_sock *xs, struct xdp_buff *xdp)
{
@@ -241,6 +287,21 @@ static inline struct xdp_umem *xdp_get_umem_from_qid(struct net_device *dev,
return NULL;
}
+static inline u64 xsk_umem_extract_addr(u64 addr)
+{
+ return 0;
+}
+
+static inline u64 xsk_umem_extract_offset(u64 addr)
+{
+ return 0;
+}
+
+static inline u64 xsk_umem_add_offset_to_addr(u64 addr)
+{
+ return 0;
+}
+
static inline char *xdp_umem_get_data(struct xdp_umem *umem, u64 addr)
{
return NULL;
@@ -290,6 +351,12 @@ static inline bool xsk_umem_uses_need_wakeup(struct xdp_umem *umem)
return false;
}
+static inline u64 xsk_umem_adjust_offset(struct xdp_umem *umem, u64 handle,
+ u64 offset)
+{
+ return 0;
+}
+
#endif /* CONFIG_XDP_SOCKETS */
#endif /* _LINUX_XDP_SOCK_H */
diff --git a/include/uapi/linux/if_xdp.h b/include/uapi/linux/if_xdp.h
index 62b80d57b72a..be328c59389d 100644
--- a/include/uapi/linux/if_xdp.h
+++ b/include/uapi/linux/if_xdp.h
@@ -26,6 +26,9 @@
*/
#define XDP_USE_NEED_WAKEUP (1 << 3)
+/* Flags for xsk_umem_config flags */
+#define XDP_UMEM_UNALIGNED_CHUNK_FLAG (1 << 0)
+
struct sockaddr_xdp {
__u16 sxdp_family;
__u16 sxdp_flags;
@@ -66,6 +69,7 @@ struct xdp_umem_reg {
__u64 len; /* Length of packet data area */
__u32 chunk_size;
__u32 headroom;
+ __u32 flags;
};
struct xdp_statistics {
@@ -87,6 +91,11 @@ struct xdp_options {
#define XDP_UMEM_PGOFF_FILL_RING 0x100000000ULL
#define XDP_UMEM_PGOFF_COMPLETION_RING 0x180000000ULL
+/* Masks for unaligned chunks mode */
+#define XSK_UNALIGNED_BUF_OFFSET_SHIFT 48
+#define XSK_UNALIGNED_BUF_ADDR_MASK \
+ ((1ULL << XSK_UNALIGNED_BUF_OFFSET_SHIFT) - 1)
+
/* Rx/Tx descriptor */
struct xdp_desc {
__u64 addr;
diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
index 2d65779282a1..e997b263a0dd 100644
--- a/net/xdp/xdp_umem.c
+++ b/net/xdp/xdp_umem.c
@@ -340,6 +340,7 @@ static int xdp_umem_account_pages(struct xdp_umem *umem)
static int xdp_umem_reg(struct xdp_umem *umem, struct xdp_umem_reg *mr)
{
+ bool unaligned_chunks = mr->flags & XDP_UMEM_UNALIGNED_CHUNK_FLAG;
u32 chunk_size = mr->chunk_size, headroom = mr->headroom;
unsigned int chunks, chunks_per_page;
u64 addr = mr->addr, size = mr->len;
@@ -355,7 +356,11 @@ static int xdp_umem_reg(struct xdp_umem *umem, struct xdp_umem_reg *mr)
return -EINVAL;
}
- if (!is_power_of_2(chunk_size))
+ if (mr->flags & ~(XDP_UMEM_UNALIGNED_CHUNK_FLAG |
+ XDP_UMEM_USES_NEED_WAKEUP))
+ return -EINVAL;
+
+ if (!unaligned_chunks && !is_power_of_2(chunk_size))
return -EINVAL;
if (!PAGE_ALIGNED(addr)) {
@@ -372,9 +377,11 @@ static int xdp_umem_reg(struct xdp_umem *umem, struct xdp_umem_reg *mr)
if (chunks == 0)
return -EINVAL;
- chunks_per_page = PAGE_SIZE / chunk_size;
- if (chunks < chunks_per_page || chunks % chunks_per_page)
- return -EINVAL;
+ if (!unaligned_chunks) {
+ chunks_per_page = PAGE_SIZE / chunk_size;
+ if (chunks < chunks_per_page || chunks % chunks_per_page)
+ return -EINVAL;
+ }
headroom = ALIGN(headroom, 64);
@@ -383,13 +390,15 @@ static int xdp_umem_reg(struct xdp_umem *umem, struct xdp_umem_reg *mr)
return -EINVAL;
umem->address = (unsigned long)addr;
- umem->chunk_mask = ~((u64)chunk_size - 1);
+ umem->chunk_mask = unaligned_chunks ? XSK_UNALIGNED_BUF_ADDR_MASK
+ : ~((u64)chunk_size - 1);
umem->size = size;
umem->headroom = headroom;
umem->chunk_size_nohr = chunk_size - headroom;
umem->npgs = size / PAGE_SIZE;
umem->pgs = NULL;
umem->user = NULL;
+ umem->flags = mr->flags;
INIT_LIST_HEAD(&umem->xsk_list);
spin_lock_init(&umem->xsk_list_lock);
diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
index ee4428a892fa..907e5f12338f 100644
--- a/net/xdp/xsk.c
+++ b/net/xdp/xsk.c
@@ -45,7 +45,7 @@ EXPORT_SYMBOL(xsk_umem_has_addrs);
u64 *xsk_umem_peek_addr(struct xdp_umem *umem, u64 *addr)
{
- return xskq_peek_addr(umem->fq, addr);
+ return xskq_peek_addr(umem->fq, addr, umem);
}
EXPORT_SYMBOL(xsk_umem_peek_addr);
@@ -115,21 +115,43 @@ bool xsk_umem_uses_need_wakeup(struct xdp_umem *umem)
}
EXPORT_SYMBOL(xsk_umem_uses_need_wakeup);
+/* If a buffer crosses a page boundary, we need to do 2 memcpy's, one for
+ * each page. This is only required in copy mode.
+ */
+static void __xsk_rcv_memcpy(struct xdp_umem *umem, u64 addr, void *from_buf,
+ u32 len, u32 metalen)
+{
+ void *to_buf = xdp_umem_get_data(umem, addr);
+
+ addr = xsk_umem_add_offset_to_addr(addr);
+ if (xskq_crosses_non_contig_pg(umem, addr, len + metalen)) {
+ void *next_pg_addr = umem->pages[(addr >> PAGE_SHIFT) + 1].addr;
+ u64 page_start = addr & ~(PAGE_SIZE - 1);
+ u64 first_len = PAGE_SIZE - (addr - page_start);
+
+ memcpy(to_buf, from_buf, first_len + metalen);
+ memcpy(next_pg_addr, from_buf + first_len, len - first_len);
+
+ return;
+ }
+
+ memcpy(to_buf, from_buf, len + metalen);
+}
+
static int __xsk_rcv(struct xdp_sock *xs, struct xdp_buff *xdp, u32 len)
{
- void *to_buf, *from_buf;
+ u64 offset = xs->umem->headroom;
+ u64 addr, memcpy_addr;
+ void *from_buf;
u32 metalen;
- u64 addr;
int err;
- if (!xskq_peek_addr(xs->umem->fq, &addr) ||
+ if (!xskq_peek_addr(xs->umem->fq, &addr, xs->umem) ||
len > xs->umem->chunk_size_nohr - XDP_PACKET_HEADROOM) {
xs->rx_dropped++;
return -ENOSPC;
}
- addr += xs->umem->headroom;
-
if (unlikely(xdp_data_meta_unsupported(xdp))) {
from_buf = xdp->data;
metalen = 0;
@@ -138,9 +160,11 @@ static int __xsk_rcv(struct xdp_sock *xs, struct xdp_buff *xdp, u32 len)
metalen = xdp->data - xdp->data_meta;
}
- to_buf = xdp_umem_get_data(xs->umem, addr);
- memcpy(to_buf, from_buf, len + metalen);
- addr += metalen;
+ memcpy_addr = xsk_umem_adjust_offset(xs->umem, addr, offset);
+ __xsk_rcv_memcpy(xs->umem, memcpy_addr, from_buf, len, metalen);
+
+ offset += metalen;
+ addr = xsk_umem_adjust_offset(xs->umem, addr, offset);
err = xskq_produce_batch_desc(xs->rx, addr, len);
if (!err) {
xskq_discard_addr(xs->umem->fq);
@@ -185,6 +209,7 @@ int xsk_generic_rcv(struct xdp_sock *xs, struct xdp_buff *xdp)
{
u32 metalen = xdp->data - xdp->data_meta;
u32 len = xdp->data_end - xdp->data;
+ u64 offset = xs->umem->headroom;
void *buffer;
u64 addr;
int err;
@@ -196,17 +221,17 @@ int xsk_generic_rcv(struct xdp_sock *xs, struct xdp_buff *xdp)
goto out_unlock;
}
- if (!xskq_peek_addr(xs->umem->fq, &addr) ||
+ if (!xskq_peek_addr(xs->umem->fq, &addr, xs->umem) ||
len > xs->umem->chunk_size_nohr - XDP_PACKET_HEADROOM) {
err = -ENOSPC;
goto out_drop;
}
- addr += xs->umem->headroom;
-
- buffer = xdp_umem_get_data(xs->umem, addr);
+ buffer = xdp_umem_get_data(xs->umem, addr + offset);
memcpy(buffer, xdp->data_meta, len + metalen);
- addr += metalen;
+ offset += metalen;
+
+ addr = xsk_umem_adjust_offset(xs->umem, addr, offset);
err = xskq_produce_batch_desc(xs->rx, addr, len);
if (err)
goto out_drop;
@@ -250,7 +275,7 @@ bool xsk_umem_consume_tx(struct xdp_umem *umem, struct xdp_desc *desc)
rcu_read_lock();
list_for_each_entry_rcu(xs, &umem->xsk_list, list) {
- if (!xskq_peek_desc(xs->tx, desc))
+ if (!xskq_peek_desc(xs->tx, desc, umem))
continue;
if (xskq_produce_addr_lazy(umem->cq, desc->addr))
@@ -304,7 +329,7 @@ static int xsk_generic_xmit(struct sock *sk, struct msghdr *m,
if (xs->queue_id >= xs->dev->real_num_tx_queues)
goto out;
- while (xskq_peek_desc(xs->tx, &desc)) {
+ while (xskq_peek_desc(xs->tx, &desc, xs->umem)) {
char *buffer;
u64 addr;
u32 len;
@@ -333,7 +358,7 @@ static int xsk_generic_xmit(struct sock *sk, struct msghdr *m,
skb->dev = xs->dev;
skb->priority = sk->sk_priority;
skb->mark = sk->sk_mark;
- skb_shinfo(skb)->destructor_arg = (void *)(long)addr;
+ skb_shinfo(skb)->destructor_arg = (void *)(long)desc.addr;
skb->destructor = xsk_destruct_skb;
err = dev_direct_xmit(skb, xs->queue_id);
@@ -526,6 +551,24 @@ static struct socket *xsk_lookup_xsk_from_fd(int fd)
return sock;
}
+/* Check if umem pages are contiguous.
+ * If zero-copy mode, use the DMA address to do the page contiguity check
+ * For all other modes we use addr (kernel virtual address)
+ * Store the result in the low bits of addr.
+ */
+static void xsk_check_page_contiguity(struct xdp_umem *umem, u32 flags)
+{
+ struct xdp_umem_page *pgs = umem->pages;
+ int i, is_contig;
+
+ for (i = 0; i < umem->npgs - 1; i++) {
+ is_contig = (flags & XDP_ZEROCOPY) ?
+ (pgs[i].dma + PAGE_SIZE == pgs[i + 1].dma) :
+ (pgs[i].addr + PAGE_SIZE == pgs[i + 1].addr);
+ pgs[i].addr += is_contig << XSK_NEXT_PG_CONTIG_SHIFT;
+ }
+}
+
static int xsk_bind(struct socket *sock, struct sockaddr *addr, int addr_len)
{
struct sockaddr_xdp *sxdp = (struct sockaddr_xdp *)addr;
@@ -616,6 +659,8 @@ static int xsk_bind(struct socket *sock, struct sockaddr *addr, int addr_len)
err = xdp_umem_assign_dev(xs->umem, dev, qid, flags);
if (err)
goto out_unlock;
+
+ xsk_check_page_contiguity(xs->umem, flags);
}
xs->dev = dev;
@@ -636,6 +681,13 @@ static int xsk_bind(struct socket *sock, struct sockaddr *addr, int addr_len)
return err;
}
+struct xdp_umem_reg_v1 {
+ __u64 addr; /* Start of packet data area */
+ __u64 len; /* Length of packet data area */
+ __u32 chunk_size;
+ __u32 headroom;
+};
+
static int xsk_setsockopt(struct socket *sock, int level, int optname,
char __user *optval, unsigned int optlen)
{
@@ -673,10 +725,16 @@ static int xsk_setsockopt(struct socket *sock, int level, int optname,
}
case XDP_UMEM_REG:
{
- struct xdp_umem_reg mr;
+ size_t mr_size = sizeof(struct xdp_umem_reg);
+ struct xdp_umem_reg mr = {};
struct xdp_umem *umem;
- if (copy_from_user(&mr, optval, sizeof(mr)))
+ if (optlen < sizeof(struct xdp_umem_reg_v1))
+ return -EINVAL;
+ else if (optlen < sizeof(mr))
+ mr_size = sizeof(struct xdp_umem_reg_v1);
+
+ if (copy_from_user(&mr, optval, mr_size))
return -EFAULT;
mutex_lock(&xs->mutex);
diff --git a/net/xdp/xsk_diag.c b/net/xdp/xsk_diag.c
index d5e06c8e0cbf..9986a759fe06 100644
--- a/net/xdp/xsk_diag.c
+++ b/net/xdp/xsk_diag.c
@@ -56,7 +56,7 @@ static int xsk_diag_put_umem(const struct xdp_sock *xs, struct sk_buff *nlskb)
du.id = umem->id;
du.size = umem->size;
du.num_pages = umem->npgs;
- du.chunk_size = (__u32)(~umem->chunk_mask + 1);
+ du.chunk_size = umem->chunk_size_nohr + umem->headroom;
du.headroom = umem->headroom;
du.ifindex = umem->dev ? umem->dev->ifindex : 0;
du.queue_id = umem->queue_id;
diff --git a/net/xdp/xsk_queue.h b/net/xdp/xsk_queue.h
index dd9e985c2461..6c67c9d0294f 100644
--- a/net/xdp/xsk_queue.h
+++ b/net/xdp/xsk_queue.h
@@ -134,6 +134,17 @@ static inline bool xskq_has_addrs(struct xsk_queue *q, u32 cnt)
/* UMEM queue */
+static inline bool xskq_crosses_non_contig_pg(struct xdp_umem *umem, u64 addr,
+ u64 length)
+{
+ bool cross_pg = (addr & (PAGE_SIZE - 1)) + length > PAGE_SIZE;
+ bool next_pg_contig =
+ (unsigned long)umem->pages[(addr >> PAGE_SHIFT)].addr &
+ XSK_NEXT_PG_CONTIG_MASK;
+
+ return cross_pg && !next_pg_contig;
+}
+
static inline bool xskq_is_valid_addr(struct xsk_queue *q, u64 addr)
{
if (addr >= q->size) {
@@ -144,23 +155,49 @@ static inline bool xskq_is_valid_addr(struct xsk_queue *q, u64 addr)
return true;
}
-static inline u64 *xskq_validate_addr(struct xsk_queue *q, u64 *addr)
+static inline bool xskq_is_valid_addr_unaligned(struct xsk_queue *q, u64 addr,
+ u64 length,
+ struct xdp_umem *umem)
+{
+ addr = xsk_umem_add_offset_to_addr(addr);
+ if (addr >= q->size ||
+ xskq_crosses_non_contig_pg(umem, addr, length)) {
+ q->invalid_descs++;
+ return false;
+ }
+
+ return true;
+}
+
+static inline u64 *xskq_validate_addr(struct xsk_queue *q, u64 *addr,
+ struct xdp_umem *umem)
{
while (q->cons_tail != q->cons_head) {
struct xdp_umem_ring *ring = (struct xdp_umem_ring *)q->ring;
unsigned int idx = q->cons_tail & q->ring_mask;
*addr = READ_ONCE(ring->desc[idx]) & q->chunk_mask;
+
+ if (umem->flags & XDP_UMEM_UNALIGNED_CHUNK_FLAG) {
+ if (xskq_is_valid_addr_unaligned(q, *addr,
+ umem->chunk_size_nohr,
+ umem))
+ return addr;
+ goto out;
+ }
+
if (xskq_is_valid_addr(q, *addr))
return addr;
+out:
q->cons_tail++;
}
return NULL;
}
-static inline u64 *xskq_peek_addr(struct xsk_queue *q, u64 *addr)
+static inline u64 *xskq_peek_addr(struct xsk_queue *q, u64 *addr,
+ struct xdp_umem *umem)
{
if (q->cons_tail == q->cons_head) {
smp_mb(); /* D, matches A */
@@ -171,7 +208,7 @@ static inline u64 *xskq_peek_addr(struct xsk_queue *q, u64 *addr)
smp_rmb();
}
- return xskq_validate_addr(q, addr);
+ return xskq_validate_addr(q, addr, umem);
}
static inline void xskq_discard_addr(struct xsk_queue *q)
@@ -230,8 +267,21 @@ static inline int xskq_reserve_addr(struct xsk_queue *q)
/* Rx/Tx queue */
-static inline bool xskq_is_valid_desc(struct xsk_queue *q, struct xdp_desc *d)
+static inline bool xskq_is_valid_desc(struct xsk_queue *q, struct xdp_desc *d,
+ struct xdp_umem *umem)
{
+ if (umem->flags & XDP_UMEM_UNALIGNED_CHUNK_FLAG) {
+ if (!xskq_is_valid_addr_unaligned(q, d->addr, d->len, umem))
+ return false;
+
+ if (d->len > umem->chunk_size_nohr || d->options) {
+ q->invalid_descs++;
+ return false;
+ }
+
+ return true;
+ }
+
if (!xskq_is_valid_addr(q, d->addr))
return false;
@@ -245,14 +295,15 @@ static inline bool xskq_is_valid_desc(struct xsk_queue *q, struct xdp_desc *d)
}
static inline struct xdp_desc *xskq_validate_desc(struct xsk_queue *q,
- struct xdp_desc *desc)
+ struct xdp_desc *desc,
+ struct xdp_umem *umem)
{
while (q->cons_tail != q->cons_head) {
struct xdp_rxtx_ring *ring = (struct xdp_rxtx_ring *)q->ring;
unsigned int idx = q->cons_tail & q->ring_mask;
*desc = READ_ONCE(ring->desc[idx]);
- if (xskq_is_valid_desc(q, desc))
+ if (xskq_is_valid_desc(q, desc, umem))
return desc;
q->cons_tail++;
@@ -262,7 +313,8 @@ static inline struct xdp_desc *xskq_validate_desc(struct xsk_queue *q,
}
static inline struct xdp_desc *xskq_peek_desc(struct xsk_queue *q,
- struct xdp_desc *desc)
+ struct xdp_desc *desc,
+ struct xdp_umem *umem)
{
if (q->cons_tail == q->cons_head) {
smp_mb(); /* D, matches A */
@@ -273,7 +325,7 @@ static inline struct xdp_desc *xskq_peek_desc(struct xsk_queue *q,
smp_rmb(); /* C, matches B */
}
- return xskq_validate_desc(q, desc);
+ return xskq_validate_desc(q, desc, umem);
}
static inline void xskq_discard_desc(struct xsk_queue *q)
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next v5 02/11] ixgbe: simplify Rx buffer recycle
From: Kevin Laatz @ 2019-08-22 1:44 UTC (permalink / raw)
To: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
jonathan.lemon, saeedm, maximmi, stephen
Cc: bruce.richardson, ciara.loftus, bpf, intel-wired-lan, Kevin Laatz
In-Reply-To: <20190822014427.49800-1-kevin.laatz@intel.com>
Currently, the dma, addr and handle are modified when we reuse Rx buffers
in zero-copy mode. However, this is not required as the inputs to the
function are copies, not the original values themselves. As we use the
copies within the function, we can use the original 'obi' values
directly without having to mask and add the headroom.
Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
index 9a28d98a1484..e1f743470ae9 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
@@ -201,8 +201,6 @@ ixgbe_rx_buffer *ixgbe_get_rx_buffer_zc(struct ixgbe_ring *rx_ring,
static void ixgbe_reuse_rx_buffer_zc(struct ixgbe_ring *rx_ring,
struct ixgbe_rx_buffer *obi)
{
- unsigned long mask = (unsigned long)rx_ring->xsk_umem->chunk_mask;
- u64 hr = rx_ring->xsk_umem->headroom + XDP_PACKET_HEADROOM;
u16 nta = rx_ring->next_to_alloc;
struct ixgbe_rx_buffer *nbi;
@@ -212,14 +210,9 @@ static void ixgbe_reuse_rx_buffer_zc(struct ixgbe_ring *rx_ring,
rx_ring->next_to_alloc = (nta < rx_ring->count) ? nta : 0;
/* transfer page from old buffer to new buffer */
- nbi->dma = obi->dma & mask;
- nbi->dma += hr;
-
- nbi->addr = (void *)((unsigned long)obi->addr & mask);
- nbi->addr += hr;
-
- nbi->handle = obi->handle & mask;
- nbi->handle += rx_ring->xsk_umem->headroom;
+ nbi->dma = obi->dma;
+ nbi->addr = obi->addr;
+ nbi->handle = obi->handle;
obi->addr = NULL;
obi->skb = NULL;
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next v5 01/11] i40e: simplify Rx buffer recycle
From: Kevin Laatz @ 2019-08-22 1:44 UTC (permalink / raw)
To: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
jonathan.lemon, saeedm, maximmi, stephen
Cc: bruce.richardson, ciara.loftus, bpf, intel-wired-lan, Kevin Laatz
In-Reply-To: <20190822014427.49800-1-kevin.laatz@intel.com>
Currently, the dma, addr and handle are modified when we reuse Rx buffers
in zero-copy mode. However, this is not required as the inputs to the
function are copies, not the original values themselves. As we use the
copies within the function, we can use the original 'old_bi' values
directly without having to mask and add the headroom.
Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_xsk.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_xsk.c b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
index 42c90126b6c4..2d6e82f72f48 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_xsk.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
@@ -420,8 +420,6 @@ static void i40e_reuse_rx_buffer_zc(struct i40e_ring *rx_ring,
struct i40e_rx_buffer *old_bi)
{
struct i40e_rx_buffer *new_bi = &rx_ring->rx_bi[rx_ring->next_to_alloc];
- unsigned long mask = (unsigned long)rx_ring->xsk_umem->chunk_mask;
- u64 hr = rx_ring->xsk_umem->headroom + XDP_PACKET_HEADROOM;
u16 nta = rx_ring->next_to_alloc;
/* update, and store next to alloc */
@@ -429,14 +427,9 @@ static void i40e_reuse_rx_buffer_zc(struct i40e_ring *rx_ring,
rx_ring->next_to_alloc = (nta < rx_ring->count) ? nta : 0;
/* transfer page from old buffer to new buffer */
- new_bi->dma = old_bi->dma & mask;
- new_bi->dma += hr;
-
- new_bi->addr = (void *)((unsigned long)old_bi->addr & mask);
- new_bi->addr += hr;
-
- new_bi->handle = old_bi->handle & mask;
- new_bi->handle += rx_ring->xsk_umem->headroom;
+ new_bi->dma = old_bi->dma;
+ new_bi->addr = old_bi->addr;
+ new_bi->handle = old_bi->handle;
old_bi->addr = NULL;
}
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next v5 00/11] XDP unaligned chunk placement support
From: Kevin Laatz @ 2019-08-22 1:44 UTC (permalink / raw)
To: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
jonathan.lemon, saeedm, maximmi, stephen
Cc: bruce.richardson, ciara.loftus, bpf, intel-wired-lan, Kevin Laatz
In-Reply-To: <20190730085400.10376-1-kevin.laatz@intel.com>
This patch set adds the ability to use unaligned chunks in the XDP umem.
Currently, all chunk addresses passed to the umem are masked to be chunk
size aligned (max is PAGE_SIZE). This limits where we can place chunks
within the umem as well as limiting the packet sizes that are supported.
The changes in this patch set removes these restrictions, allowing XDP to
be more flexible in where it can place a chunk within a umem. By relaxing
where the chunks can be placed, it allows us to use an arbitrary buffer
size and place that wherever we have a free address in the umem. These
changes add the ability to support arbitrary frame sizes up to 4k
(PAGE_SIZE) and make it easy to integrate with other existing frameworks
that have their own memory management systems, such as DPDK.
In DPDK, for example, there is already support for AF_XDP with zero-copy.
However, with this patch set the integration will be much more seamless.
You can find the DPDK AF_XDP driver at:
https://git.dpdk.org/dpdk/tree/drivers/net/af_xdp
Since we are now dealing with arbitrary frame sizes, we need also need to
update how we pass around addresses. Currently, the addresses can simply be
masked to 2k to get back to the original address. This becomes less trivial
when using frame sizes that are not a 'power of 2' size. This patch set
modifies the Rx/Tx descriptor format to use the upper 16-bits of the addr
field for an offset value, leaving the lower 48-bits for the address (this
leaves us with 256 Terabytes, which should be enough!). We only need to use
the upper 16-bits to store the offset when running in unaligned mode.
Rather than adding the offset (headroom etc) to the address, we will store
it in the upper 16-bits of the address field. This way, we can easily add
the offset to the address where we need it, using some bit manipulation and
addition, and we can also easily get the original address wherever we need
it (for example in i40e_zca_free) by simply masking to get the lower
48-bits of the address field.
Note: The mlx5e patch only adds support for the new offset handling. Maxim
Mikityanski <maximmi@mellanox.com> is working on an additional patch that
enables the unaligned chunks feature (makes mlx5e accept arbitrary frame
sizes) which will be added later and applies on top of this patch.
The numbers below were recorded with the following set up:
- Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz
- Intel Corporation Ethernet Controller XXV710 for 25GbE SFP28 (rev 02)
- Driver: i40e
- Application: xdpsock with l2fwd (single interface)
- Turbo disabled in BIOS
These are solely for comparing performance with and without the patches.
The largest drop was ~1.5% (in zero-copy mode).
+-------------------------+-------------+-----------------+-------------+
| Buffer size: 2048 | SKB mode | Zero-copy | Copy |
+-------------------------+-------------+-----------------+-------------+
| Aligned (baseline) | 1.25 Mpps | 10.0 Mpps | 1.66 Mpps |
+-------------------------+-------------+-----------------+-------------+
| Aligned (with patches) | 1.25 Mpps | 9.85 Mpps | 1.66 Mpps |
+-------------------------+-------------+-----------------+-------------+
| Unaligned | 1.25 Mpps | 9.65 Mpps | 1.66 Mpps |
+-------------------------+-------------+-----------------+-------------+
This patch set has been applied against
commit 0bb52b0dfc88 ("tools: bpftool: add 'bpftool map freeze' subcommand")
Structure of the patch set:
Patch 1:
- Remove unnecessary masking and headroom addition during zero-copy Rx
buffer recycling in i40e. This change is required in order for the
buffer recycling to work in the unaligned chunk mode.
Patch 2:
- Remove unnecessary masking and headroom addition during
zero-copy Rx buffer recycling in ixgbe. This change is required in
order for the buffer recycling to work in the unaligned chunk mode.
Patch 3:
- Add infrastructure for unaligned chunks. Since we are dealing with
unaligned chunks that could potentially cross a physical page boundary,
we add checks to keep track of that information. We can later use this
information to correctly handle buffers that are placed at an address
where they cross a page boundary. This patch also modifies the
existing Rx and Tx functions to use the new descriptor format. To
handle addresses correctly, we need to mask appropriately based on
whether we are in aligned or unaligned mode.
Patch 4:
- This patch updates the i40e driver to make use of the new descriptor
format.
Patch 5:
- This patch updates the ixgbe driver to make use of the new descriptor
format.
Patch 6:
- This patch updates the mlx5e driver to make use of the new descriptor
format. These changes are required to handle the new descriptor format
and for unaligned chunks support.
Patch 7:
- Add flags for umem configuration to libbpf. Since we increase the size
of the struct by adding flags, we also need to add the ABI versioning
in this patch.
Patch 8:
- Modify xdpsock application to add a command line option for
unaligned chunks
Patch 9:
- Since we can now run the application in unaligned chunk mode, we need
to make sure we recycle the buffers appropriately.
Patch 10:
- Adds hugepage support to the xdpsock application
Patch 11:
- Documentation update to include the unaligned chunk scenario. We need
to explicitly state that the incoming addresses are only masked in the
aligned chunk mode and not the unaligned chunk mode.
---
v2:
- fixed checkpatch issues
- fixed Rx buffer recycling for unaligned chunks in xdpsock
- removed unused defines
- fixed how chunk_size is calculated in xsk_diag.c
- added some performance numbers to cover letter
- modified descriptor format to make it easier to retrieve original
address
- removed patch adding off_t off to the zero copy allocator. This is no
longer needed with the new descriptor format.
v3:
- added patch for mlx5 driver changes needed for unaligned chunks
- moved offset handling to new helper function
- changed value used for the umem chunk_mask. Now using the new
descriptor format to save us doing the calculations in a number of
places meaning more of the code is left unchanged while adding
unaligned chunk support.
v4:
- reworked the next_pg_contig field in the xdp_umem_page struct. We now
use the low 12 bits of the addr for flags rather than adding an extra
field in the struct.
- modified unaligned chunks flag define
- fixed page_start calculation in __xsk_rcv_memcpy().
- move offset handling to the xdp_umem_get_* functions
- modified the len field in xdp_umem_reg struct. We now use 16 bits from
this for the flags field.
- fixed headroom addition to handle in the mlx5e driver
- other minor changes based on review comments
v5:
- Added ABI versioning in the libbpf patch
- Removed bitfields in the xdp_umem_reg struct. Adding new flags field.
- Added accessors for getting addr and offset.
- Added helper function for adding the offset to the addr.
- Fixed conflicts with 'bpf-af-xdp-wakeup' which was merged recently.
- Fixed typo in mlx driver patch.
- Moved libbpf patch to later in the set (7/11, just before the sample
app changes)
Kevin Laatz (11):
i40e: simplify Rx buffer recycle
ixgbe: simplify Rx buffer recycle
xsk: add support to allow unaligned chunk placement
i40e: modify driver for handling offsets
ixgbe: modify driver for handling offsets
mlx5e: modify driver for handling offsets
libbpf: add flags to umem config
samples/bpf: add unaligned chunks mode support to xdpsock
samples/bpf: add buffer recycling for unaligned chunks to xdpsock
samples/bpf: use hugepages in xdpsock app
doc/af_xdp: include unaligned chunk case
Documentation/networking/af_xdp.rst | 10 +-
drivers/net/ethernet/intel/i40e/i40e_xsk.c | 26 +++--
drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 26 +++--
.../net/ethernet/mellanox/mlx5/core/en/xdp.c | 8 +-
.../ethernet/mellanox/mlx5/core/en/xsk/rx.c | 3 +-
include/net/xdp_sock.h | 75 ++++++++++++++-
include/uapi/linux/if_xdp.h | 9 ++
net/xdp/xdp_umem.c | 19 +++-
net/xdp/xsk.c | 96 +++++++++++++++----
net/xdp/xsk_diag.c | 2 +-
net/xdp/xsk_queue.h | 68 +++++++++++--
samples/bpf/xdpsock_user.c | 61 ++++++++----
tools/include/uapi/linux/if_xdp.h | 9 ++
tools/lib/bpf/Makefile | 5 +-
tools/lib/bpf/libbpf.map | 1 +
tools/lib/bpf/xsk.c | 33 ++++++-
tools/lib/bpf/xsk.h | 27 ++++++
17 files changed, 384 insertions(+), 94 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
From: Jiri Pirko @ 2019-08-22 9:58 UTC (permalink / raw)
To: Parav Pandit
Cc: Alex Williamson, Jiri Pirko, David S . Miller, Kirti Wankhede,
Cornelia Huck, kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
cjia, netdev@vger.kernel.org
In-Reply-To: <AM0PR05MB4866A20F831A5D42E6C79EFED1A50@AM0PR05MB4866.eurprd05.prod.outlook.com>
Thu, Aug 22, 2019 at 11:42:13AM CEST, parav@mellanox.com wrote:
>
>
>> -----Original Message-----
>> From: Jiri Pirko <jiri@resnulli.us>
>> Sent: Thursday, August 22, 2019 2:59 PM
>> To: Parav Pandit <parav@mellanox.com>
>> Cc: Alex Williamson <alex.williamson@redhat.com>; Jiri Pirko
>> <jiri@mellanox.com>; David S . Miller <davem@davemloft.net>; Kirti
>> Wankhede <kwankhede@nvidia.com>; Cornelia Huck <cohuck@redhat.com>;
>> kvm@vger.kernel.org; linux-kernel@vger.kernel.org; cjia <cjia@nvidia.com>;
>> netdev@vger.kernel.org
>> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
>>
>> Wed, Aug 21, 2019 at 08:23:17AM CEST, parav@mellanox.com wrote:
>> >
>> >
>> >> -----Original Message-----
>> >> From: Alex Williamson <alex.williamson@redhat.com>
>> >> Sent: Wednesday, August 21, 2019 10:56 AM
>> >> To: Parav Pandit <parav@mellanox.com>
>> >> Cc: Jiri Pirko <jiri@mellanox.com>; David S . Miller
>> >> <davem@davemloft.net>; Kirti Wankhede <kwankhede@nvidia.com>;
>> >> Cornelia Huck <cohuck@redhat.com>; kvm@vger.kernel.org;
>> >> linux-kernel@vger.kernel.org; cjia <cjia@nvidia.com>;
>> >> netdev@vger.kernel.org
>> >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
>> >>
>> >> > > > > Just an example of the alias, not proposing how it's set. In
>> >> > > > > fact, proposing that the user does not set it, mdev-core
>> >> > > > > provides one
>> >> > > automatically.
>> >> > > > >
>> >> > > > > > > Since there seems to be some prefix overhead, as I ask
>> >> > > > > > > about above in how many characters we actually have to
>> >> > > > > > > work with in IFNAMESZ, maybe we start with 8 characters
>> >> > > > > > > (matching your "index" namespace) and expand as necessary for
>> disambiguation.
>> >> > > > > > > If we can eliminate overhead in IFNAMESZ, let's start with 12.
>> >> > > > > > > Thanks,
>> >> > > > > > >
>> >> > > > > > If user is going to choose the alias, why does it have to
>> >> > > > > > be limited to
>> >> sha1?
>> >> > > > > > Or you just told it as an example?
>> >> > > > > >
>> >> > > > > > It can be an alpha-numeric string.
>> >> > > > >
>> >> > > > > No, I'm proposing a different solution where mdev-core
>> >> > > > > creates an alias based on an abbreviated sha1. The user does
>> >> > > > > not provide the
>> >> alias.
>> >> > > > >
>> >> > > > > > Instead of mdev imposing number of characters on the alias,
>> >> > > > > > it should be best
>> >> > > > > left to the user.
>> >> > > > > > Because in future if netdev improves on the naming scheme,
>> >> > > > > > mdev will be
>> >> > > > > limiting it, which is not right.
>> >> > > > > > So not restricting alias size seems right to me.
>> >> > > > > > User configuring mdev for networking devices in a given
>> >> > > > > > kernel knows what
>> >> > > > > user is doing.
>> >> > > > > > So user can choose alias name size as it finds suitable.
>> >> > > > >
>> >> > > > > That's not what I'm proposing, please read again. Thanks,
>> >> > > >
>> >> > > > I understood your point. But mdev doesn't know how user is
>> >> > > > going to use
>> >> > > udev/systemd to name the netdev.
>> >> > > > So even if mdev chose to pick 12 characters, it could result in collision.
>> >> > > > Hence the proposal to provide the alias by the user, as user
>> >> > > > know the best
>> >> > > policy for its use case in the environment its using.
>> >> > > > So 12 character sha1 method will still work by user.
>> >> > >
>> >> > > Haven't you already provided examples where certain drivers or
>> >> > > subsystems have unique netdev prefixes? If mdev provides a
>> >> > > unique alias within the subsystem, couldn't we simply define a
>> >> > > netdev prefix for the mdev subsystem and avoid all other
>> >> > > collisions? I'm not in favor of the user providing both a uuid
>> >> > > and an alias/instance. Thanks,
>> >> > >
>> >> > For a given prefix, say ens2f0, can two UUID->sha1 first 9
>> >> > characters have
>> >> collision?
>> >>
>> >> I think it would be a mistake to waste so many chars on a prefix, but
>> >> 9 characters of sha1 likely wouldn't have a collision before we have
>> >> 10s of thousands of devices. Thanks,
>> >>
>> >> Alex
>> >
>> >Jiri, Dave,
>> >Are you ok with it for devlink/netdev part?
>> >Mdev core will create an alias from a UUID.
>> >
>> >This will be supplied during devlink port attr set such as,
>> >
>> >devlink_port_attrs_mdev_set(struct devlink_port *port, const char
>> >*mdev_alias);
>> >
>> >This alias is used to generate representor netdev's phys_port_name.
>> >This alias from the mdev device's sysfs will be used by the udev/systemd to
>> generate predicable netdev's name.
>> >Example: enm<mdev_alias_first_12_chars>
>>
>> What happens in unlikely case of 2 UUIDs collide?
>>
>Since users sees two devices with same phys_port_name, user should destroy recently created mdev and recreate mdev with different UUID?
Driver should make sure phys port name wont collide, in this case that
it does not provide 2 same attrs for 2 different ports.
Hmm, so the order of creation matters. That is not good.
>>
>> >I took Ethernet mdev as an example.
>> >New prefix 'm' stands for mediated device.
>> >Remaining 12 characters are first 12 chars of the mdev alias.
>>
>> Does this resolve the identification of devlink port representor?
>Not sure if I understood your question correctly, attemping to answer below.
>phys_port_name of devlink port is defined by the first 12 characters of mdev alias.
>> I assume you want to use the same 12(or so) chars, don't you?
>Mdev's netdev will also use the same mdev alias from the sysfs to rename netdev name from ethX to enm<mdev_alias>, where en=Etherenet, m=mdev.
>
>So yes, same 12 characters are use for mdev's netdev and mdev devlink port's phys_port_name.
>
>Is that what are you asking?
Yes. Then you have 3 chars to handle the rest of the name (pci, pf)...
^ 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