* Re: [net-next PATCH 8/9] bpf: sockmap requires STREAM_PARSER add Kconfig entry
From: Alexei Starovoitov @ 2017-08-28 17:34 UTC (permalink / raw)
To: John Fastabend; +Cc: ast, daniel, davem, netdev
In-Reply-To: <20170828141221.14143.27371.stgit@john-Precision-Tower-5810>
On Mon, Aug 28, 2017 at 07:12:21AM -0700, John Fastabend wrote:
> SOCKMAP uses strparser code (compiled with Kconfig option
> CONFIG_STREAM_PARSER) to run the parser BPF program. Without this
> config option set sockmap wont be compiled. However, at the moment
> the only way to pull in the strparser code is to enable KCM.
>
> To resolve this create a BPF specific config option to pull
> only the strparser piece in that sockmap needs. This also
> allows folks who want to use BPF/syscall/maps but don't need
> sockmap to easily opt out.
>
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* Re: [net-next PATCH 6/9] bpf: harden sockmap program attach to ensure correct map type
From: Alexei Starovoitov @ 2017-08-28 17:33 UTC (permalink / raw)
To: John Fastabend; +Cc: ast, daniel, davem, netdev
In-Reply-To: <20170828141143.14143.89655.stgit@john-Precision-Tower-5810>
On Mon, Aug 28, 2017 at 07:11:43AM -0700, John Fastabend wrote:
> When attaching a program to sockmap we need to check map type
> is correct.
>
> Fixes: 174a79ff9515 ("bpf: sockmap with sk redirect support")
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
good catch. Great to see that you're adding a test for it too.
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* [iproute PATCH] ss: Fix for added diag support check
From: Phil Sutter @ 2017-08-28 17:31 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
Commit 9f66764e308e9 ("libnetlink: Add test for error code returned from
netlink reply") changed rtnl_dump_filter_l() to return an error in case
NLMSG_DONE would contain one, even if it was ENOENT.
This in turn breaks ss when it tries to dump DCCP sockets on a system
without support for it: The function tcp_show(), which is shared between
TCP and DCCP, will start parsing /proc since inet_show_netlink() returns
an error - yet it parses /proc/net/tcp which doesn't make sense for DCCP
sockets at all.
On my system, a call to 'ss' without further arguments prints the list
of connected TCP sockets twice.
Fix this by introducing a dedicated function dccp_show() which does not
have a fallback to /proc, just like sctp_show(). And since tcp_show()
is no longer "multi-purpose", drop it's socktype parameter.
Fixes: 9f66764e308e9 ("libnetlink: Add test for error code returned from netlink reply")
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
misc/ss.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/misc/ss.c b/misc/ss.c
index fcc3cf9282c49..2c9e80e696595 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -2753,7 +2753,7 @@ static int tcp_show_netlink_file(struct filter *f)
return err;
}
-static int tcp_show(struct filter *f, int socktype)
+static int tcp_show(struct filter *f)
{
FILE *fp = NULL;
char *buf = NULL;
@@ -2768,7 +2768,7 @@ static int tcp_show(struct filter *f, int socktype)
return tcp_show_netlink_file(f);
if (!getenv("PROC_NET_TCP") && !getenv("PROC_ROOT")
- && inet_show_netlink(f, NULL, socktype) == 0)
+ && inet_show_netlink(f, NULL, IPPROTO_TCP) == 0)
return 0;
/* Sigh... We have to parse /proc/net/tcp... */
@@ -2836,6 +2836,18 @@ outerr:
} while (0);
}
+static int dccp_show(struct filter *f)
+{
+ if (!filter_af_get(f, AF_INET) && !filter_af_get(f, AF_INET6))
+ return 0;
+
+ if (!getenv("PROC_NET_DCCP") && !getenv("PROC_ROOT")
+ && inet_show_netlink(f, NULL, IPPROTO_DCCP) == 0)
+ return 0;
+
+ return 0;
+}
+
static int sctp_show(struct filter *f)
{
if (!filter_af_get(f, AF_INET) && !filter_af_get(f, AF_INET6))
@@ -4390,9 +4402,9 @@ int main(int argc, char *argv[])
if (current_filter.dbs & (1<<UDP_DB))
udp_show(¤t_filter);
if (current_filter.dbs & (1<<TCP_DB))
- tcp_show(¤t_filter, IPPROTO_TCP);
+ tcp_show(¤t_filter);
if (current_filter.dbs & (1<<DCCP_DB))
- tcp_show(¤t_filter, IPPROTO_DCCP);
+ dccp_show(¤t_filter);
if (current_filter.dbs & (1<<SCTP_DB))
sctp_show(¤t_filter);
--
2.13.1
^ permalink raw reply related
* Re: [net-next PATCH 2/9] bpf: sockmap, remove STRPARSER map_flags and add multi-map support
From: Alexei Starovoitov @ 2017-08-28 17:31 UTC (permalink / raw)
To: John Fastabend; +Cc: ast, daniel, davem, netdev
In-Reply-To: <20170828141025.14143.23990.stgit@john-Precision-Tower-5810>
On Mon, Aug 28, 2017 at 07:10:25AM -0700, John Fastabend wrote:
> The addition of map_flags BPF_SOCKMAP_STRPARSER flags was to handle a
> specific use case where we want to have BPF parse program disabled on
> an entry in a sockmap.
>
> However, Alexei found the API a bit cumbersome and I agreed. Lets
> remove the STRPARSER flag and support the use case by allowing socks
> to be in multiple maps. This allows users to create two maps one with
> programs attached and one without. When socks are added to maps they
> now inherit any programs attached to the map. This is a nice
> generalization and IMO improves the API.
>
> The API rules are less ambiguous and do not need a flag:
>
> - When a sock is added to a sockmap we have two cases,
>
> i. The sock map does not have any attached programs so
> we can add sock to map without inheriting bpf programs.
> The sock may exist in 0 or more other maps.
>
> ii. The sock map has an attached BPF program. To avoid duplicate
> bpf programs we only add the sock entry if it does not have
> an existing strparser/verdict attached, returning -EBUSY if
> a program is already attached. Otherwise attach the program
> and inherit strparser/verdict programs from the sock map.
>
> This allows for socks to be in a multiple maps for redirects and
> inherit a BPF program from a single map.
>
> Also this patch simplifies the logic around BPF_{EXIST|NOEXIST|ANY}
> flags. In the original patch I tried to be extra clever and only
> update map entries when necessary. Now I've decided the complexity
> is not worth it. If users constantly update an entry with the same
> sock for no reason (i.e. update an entry without actually changing
> any parameters on map or sock) we still do an alloc/release. Using
> this and allowing multiple entries of a sock to exist in a map the
> logic becomes much simpler.
>
> Note: Now that multiple maps are supported the "maps" pointer called
> when a socket is closed becomes a list of maps to remove the sock from.
> To keep the map up to date when a sock is added to the sockmap we must
> add the map/elem in the list. Likewise when it is removed we must
> remove it from the list. This results in searching the per psock list
> on delete operation. On TCP_CLOSE events we walk the list and remove
> the psock from all map/entry locations. I don't see any perf
> implications in this because at most I have a psock in two maps. If
> a psock were to be in many maps its possibly this might be noticeable
> on delete but I can't think of a reason to dup a psock in many maps.
> The sk_callback_lock is used to protect read/writes to the list. This
> was convenient because in all locations we were taking the lock
> anyways just after working on the list. Also the lock is per sock so
> in normal cases we shouldn't see any contention.
>
> Suggested-by: Alexei Starovoitov <ast@kernel.org>
> Fixes: 174a79ff9515 ("bpf: sockmap with sk redirect support")
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
nice. I think implementation got cleaner too.
thanks for addresing the comments quickly!
Acked-by: Alexei Starovoitov <ast@kernel.org>
> ---
> include/uapi/linux/bpf.h | 3 -
> kernel/bpf/sockmap.c | 269 ++++++++++++++++++++++++++++------------------
> 2 files changed, 165 insertions(+), 107 deletions(-)
>
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 97227be..08c206a 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -143,9 +143,6 @@ enum bpf_attach_type {
>
> #define MAX_BPF_ATTACH_TYPE __MAX_BPF_ATTACH_TYPE
>
> -/* If BPF_SOCKMAP_STRPARSER is used sockmap will use strparser on receive */
> -#define BPF_SOCKMAP_STRPARSER (1U << 0)
> -
Please update tools/include/uapi/linux/bpf.h as well.
Right now it's kinda messed up and still has:
enum bpf_sockmap_flags {
BPF_SOCKMAP_UNSPEC,
BPF_SOCKMAP_STRPARSER,
__MAX_BPF_SOCKMAP_FLAG
};
that's separate patch of course. Not a blocker for this set.
^ permalink raw reply
* Re: [net-next PATCH 1/9] bpf: convert sockmap field attach_bpf_fd2 to type
From: Alexei Starovoitov @ 2017-08-28 17:22 UTC (permalink / raw)
To: John Fastabend; +Cc: ast, daniel, davem, netdev
In-Reply-To: <20170828141004.14143.19285.stgit@john-Precision-Tower-5810>
On Mon, Aug 28, 2017 at 07:10:04AM -0700, John Fastabend wrote:
> In the initial sockmap API we provided strparser and verdict programs
> using a single attach command by extending the attach API with a the
> attach_bpf_fd2 field.
>
> However, if we add other programs in the future we will be adding a
> field for every new possible type, attach_bpf_fd(3,4,..). This
> seems a bit clumsy for an API. So lets push the programs using two
> new type fields.
>
> BPF_SK_SKB_STREAM_PARSER
> BPF_SK_SKB_STREAM_VERDICT
>
> This has the advantage of having a readable name and can easily be
> extended in the future.
>
> Updates to samples and sockmap included here also generalize tests
> slightly to support upcoming patch for multiple map support.
>
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
> Fixes: 174a79ff9515 ("bpf: sockmap with sk redirect support")
> Suggested-by: Alexei Starovoitov <ast@kernel.org>
lgtm
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next] selftests/bpf: check the instruction dumps are populated
From: Martin KaFai Lau @ 2017-08-28 17:19 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, daniel, oss-drivers
In-Reply-To: <20170825213957.4768-1-jakub.kicinski@netronome.com>
On Fri, Aug 25, 2017 at 02:39:57PM -0700, Jakub Kicinski wrote:
> Add a basic test for checking whether kernel is populating
> the jited and xlated BPF images. It was used to confirm
> the behaviour change from commit d777b2ddbecf ("bpf: don't
> zero out the info struct in bpf_obj_get_info_by_fd()"),
> which made bpf_obj_get_info_by_fd() usable for retrieving
> the image dumps.
Acked-by: Martin KaFai Lau <kafai@fb.com>
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> ---
> tools/testing/selftests/bpf/test_progs.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/test_progs.c b/tools/testing/selftests/bpf/test_progs.c
> index 1cb037803679..11ee25cea227 100644
> --- a/tools/testing/selftests/bpf/test_progs.c
> +++ b/tools/testing/selftests/bpf/test_progs.c
> @@ -279,7 +279,7 @@ static void test_bpf_obj_id(void)
> /* +1 to test for the info_len returned by kernel */
> struct bpf_prog_info prog_infos[nr_iters + 1];
> struct bpf_map_info map_infos[nr_iters + 1];
> - char jited_insns[128], xlated_insns[128];
> + char jited_insns[128], xlated_insns[128], zeros[128];
> __u32 i, next_id, info_len, nr_id_found, duration = 0;
> int sysctl_fd, jit_enabled = 0, err = 0;
> __u64 array_value;
> @@ -305,6 +305,7 @@ static void test_bpf_obj_id(void)
> objs[i] = NULL;
>
> /* Check bpf_obj_get_info_by_fd() */
> + bzero(zeros, sizeof(zeros));
> for (i = 0; i < nr_iters; i++) {
> err = bpf_prog_load(file, BPF_PROG_TYPE_SOCKET_FILTER,
> &objs[i], &prog_fds[i]);
> @@ -318,6 +319,8 @@ static void test_bpf_obj_id(void)
> /* Check getting prog info */
> info_len = sizeof(struct bpf_prog_info) * 2;
> bzero(&prog_infos[i], info_len);
> + bzero(jited_insns, sizeof(jited_insns));
> + bzero(xlated_insns, sizeof(xlated_insns));
> prog_infos[i].jited_prog_insns = ptr_to_u64(jited_insns);
> prog_infos[i].jited_prog_len = sizeof(jited_insns);
> prog_infos[i].xlated_prog_insns = ptr_to_u64(xlated_insns);
> @@ -328,15 +331,20 @@ static void test_bpf_obj_id(void)
> prog_infos[i].type != BPF_PROG_TYPE_SOCKET_FILTER ||
> info_len != sizeof(struct bpf_prog_info) ||
> (jit_enabled && !prog_infos[i].jited_prog_len) ||
> - !prog_infos[i].xlated_prog_len,
> + (jit_enabled &&
> + !memcmp(jited_insns, zeros, sizeof(zeros))) ||
> + !prog_infos[i].xlated_prog_len ||
> + !memcmp(xlated_insns, zeros, sizeof(zeros)),
> "get-prog-info(fd)",
> - "err %d errno %d i %d type %d(%d) info_len %u(%lu) jit_enabled %d jited_prog_len %u xlated_prog_len %u\n",
> + "err %d errno %d i %d type %d(%d) info_len %u(%lu) jit_enabled %d jited_prog_len %u xlated_prog_len %u jited_prog %d xlated_prog %d\n",
> err, errno, i,
> prog_infos[i].type, BPF_PROG_TYPE_SOCKET_FILTER,
> info_len, sizeof(struct bpf_prog_info),
> jit_enabled,
> prog_infos[i].jited_prog_len,
> - prog_infos[i].xlated_prog_len))
> + prog_infos[i].xlated_prog_len,
> + !!memcmp(jited_insns, zeros, sizeof(zeros)),
> + !!memcmp(xlated_insns, zeros, sizeof(zeros))))
> goto done;
>
> map_fds[i] = bpf_find_map(__func__, objs[i], "test_map_id");
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH] igb: check memory allocation failure
From: Christophe JAILLET @ 2017-08-28 17:12 UTC (permalink / raw)
To: Waskiewicz Jr, Peter, Kirsher, Jeffrey T
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
In-Reply-To: <E0D909EE5BB15A4699798539EA149D7F0779685B@ORSMSX103.amr.corp.intel.com>
Le 28/08/2017 à 01:09, Waskiewicz Jr, Peter a écrit :
> On 8/27/17 2:42 AM, Christophe JAILLET wrote:
>> Check memory allocation failures and return -ENOMEM in such cases, as
>> already done for other memory allocations in this function.
>>
>> This avoids NULL pointers dereference.
>>
>> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>> ---
>> drivers/net/ethernet/intel/igb/igb_main.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
>> index fd4a46b03cc8..837d9b46a390 100644
>> --- a/drivers/net/ethernet/intel/igb/igb_main.c
>> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
>> @@ -3162,6 +3162,8 @@ static int igb_sw_init(struct igb_adapter *adapter)
>> /* Setup and initialize a copy of the hw vlan table array */
>> adapter->shadow_vfta = kcalloc(E1000_VLAN_FILTER_TBL_SIZE, sizeof(u32),
>> GFP_ATOMIC);
>> + if (!adapter->shadow_vfta)
>> + return -ENOMEM;
> Looks reasonable to me.
>
> A larger issue though I see in this function is that if we return
> -ENOMEM here, and if we return -ENOMEM from igb_init_interrupt_scheme()
> below on failure, we leak adapter->mac_table (and adapter->shadow_vfta
> in the latter). We should add a proper unwind to free up the memory on
> failure.
>
> -PJ
>
Hi,
in fact, there is no leak because the only caller of 'igb_sw_init()'
(i.e. 'igb_probe()'), already frees these resources in case of error,
see [1]
These resources are also freed in 'igb_remove()'.
Best reagrds,
CJ
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/net/ethernet/intel/igb/igb_main.c#n2775
^ permalink raw reply
* Re: [Intel-wired-lan] how to submit fixes for i40e/i40evf?
From: Alexander Duyck @ 2017-08-28 17:00 UTC (permalink / raw)
To: Stefano Brivio; +Cc: David S. Miller, Jeff Kirsher, Netdev, intel-wired-lan
In-Reply-To: <20170826002852.751d5f07@elisabeth>
On Fri, Aug 25, 2017 at 3:28 PM, Stefano Brivio <sbrivio@redhat.com> wrote:
> On Fri, 25 Aug 2017 15:10:08 -0700
> Alexander Duyck <alexander.duyck@gmail.com> wrote:
>
>> On Fri, Aug 25, 2017 at 1:52 PM, Stefano Brivio <sbrivio@redhat.com> wrote:
>>
>> [...]
>>
>> > Once patches reach Intel's patchwork, will they need to wait for some
>> > kind of periodically scheduled pull request process?
>>
>> Once in the patchwork they go through testing and after they have
>> passed testing Jeff will try to push them to Dave.
>
> Ok, the whole part above is clear, thanks a lot for clarifying.
>
>> > I don't know if a process is actually defined at this level of detail,
>> > but still I feel it's wrong that an obvious fix for a potential crash is
>> > waiting in some sort of limbo for 10 days now. Sure, worse things
>> > happen in the world, but I can't understand what this patch is waiting
>> > for.
>>
>> Well in the case of your patch it was rejected as it didn't apply to
>> Jeff's tree
>
> It actually did when I posted it.
>
>> and conflicted with Jacob Keller's patch. He submitted a v2 on Tuesday
>> which has only been applied for a few days. Once it receives a
>> "Tested-by:"
>
> Which, if I understood correctly, only comes after some internal testing
> process, right?
>
>> it will be ready for submission assuming it passes testing.
>
> Now that patch is again in a v2 pull request for net-next, without the
> changes I suggested for the commit message. And the same exact code
> changes were around for two weeks. IMHO there's room for improvement,
> so to speak.
>
>> I hope that helps to clarify things.
>
> It did to some extent, and thanks again for that.
One other thing I forgot that adds to the confusion is that you will
probably want to base you patch on the dev-queue branch of those
trees, not the master branch. The master branch is what Jeff submits
to Dave if I am not mistaken, while dev-queue is the location for the
ongoing development.
- Alex
^ permalink raw reply
* Re: [ethtool] ethtool: Remove UDP Fragmentation Offload use from ethtool
From: David Miller @ 2017-08-28 16:38 UTC (permalink / raw)
To: eric.dumazet; +Cc: tariqt, linville, netdev, eranbe, shakerd
In-Reply-To: <1503932411.11498.67.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 28 Aug 2017 08:00:11 -0700
> On Mon, 2017-08-28 at 15:38 +0300, Tariq Toukan wrote:
>> From: Shaker Daibes <shakerd@mellanox.com>
>>
>> UFO was removed in kernel, here we remove it in ethtool app.
>>
>> Fixes the following issue:
>> Features for ens8:
>> Cannot get device udp-fragmentation-offload settings: Operation not supported
>>
>> Tested with "make check"
>>
>> Signed-off-by: Shaker Daibes <shakerd@mellanox.com>
>> Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
>> ---
>
>
> Hi guys
>
> I would rather remove the warning, but leave the ability to switch UFO
> on machines running old kernel but a recent ethtool.
>
> ethtool does not need to be downgraded every time we boot an old
> kernel ;)
Agreed, we shouldn't be completely removing support for UFO from
ethtool.
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH] e1000e: apply burst mode settings only on default
From: Alexander Duyck @ 2017-08-28 16:25 UTC (permalink / raw)
To: Neftin, Sasha
Cc: Willem de Bruijn, "jeffrey.t.kirsher, Netdev,
Willem de Bruijn, intel-wired-lan
In-Reply-To: <291b863f-552e-2f3b-f658-e812d0848949@intel.com>
On Sun, Aug 27, 2017 at 1:30 AM, Neftin, Sasha <sasha.neftin@intel.com> wrote:
> On 8/25/2017 18:06, Willem de Bruijn wrote:
>>
>> From: Willem de Bruijn <willemb@google.com>
>>
>> Devices that support FLAG2_DMA_BURST have different default values
>> for RDTR and RADV. Apply burst mode default settings only when no
>> explicit value was passed at module load.
>>
>> The RDTR default is zero. If the module is loaded for low latency
>> operation with RxIntDelay=0, do not override this value with a burst
>> default of 32.
>>
>> Move the decision to apply burst values earlier, where explicitly
>> initialized module variables can be distinguished from defaults.
>>
>> Signed-off-by: Willem de Bruijn <willemb@google.com>
>
> This patch looks good for me, but I would like hear second opinion.
This code is an improvement over what was already there. I am good with this.
Acked-by: Alexander Duyck <alexander.h.duyck@intel.com>
^ permalink raw reply
* Re: [PATCH net 0/2] netfilter: ipvs: some fixes in sctp_conn_schedule
From: Pablo Neira Ayuso @ 2017-08-28 16:17 UTC (permalink / raw)
To: Xin Long
Cc: netfilter-devel, Alex Gartrell, lvs-devel, netdev, horms, ja,
wensong
In-Reply-To: <cover.1503207076.git.lucien.xin@gmail.com>
On Sun, Aug 20, 2017 at 01:38:06PM +0800, Xin Long wrote:
> Patch 1/2 fixes the regression introduced by commit 5e26b1b3abce.
> Patch 2/2 makes ipvs not create conn for sctp ABORT packet.
Will wait for Julian and Simon to tell me what I should do with this.
Thanks!
^ permalink raw reply
* Re: XDP redirect measurements, gotchas and tracepoints
From: John Fastabend @ 2017-08-28 16:14 UTC (permalink / raw)
To: Andy Gospodarek, Michael Chan
Cc: Jesper Dangaard Brouer, Alexander Duyck, Duyck, Alexander H,
pstaszewski@itcare.pl, netdev@vger.kernel.org,
xdp-newbies@vger.kernel.org, borkmann@iogearbox.net
In-Reply-To: <20170828160237.GA70910@C02RW35GFVH8.dhcp.broadcom.net>
On 08/28/2017 09:02 AM, Andy Gospodarek wrote:
> On Fri, Aug 25, 2017 at 08:28:55AM -0700, Michael Chan wrote:
>> On Fri, Aug 25, 2017 at 8:10 AM, John Fastabend
>> <john.fastabend@gmail.com> wrote:
>>> On 08/25/2017 05:45 AM, Jesper Dangaard Brouer wrote:
>>>> On Thu, 24 Aug 2017 20:36:28 -0700
>>>> Michael Chan <michael.chan@broadcom.com> wrote:
>>>>
>>>>> On Wed, Aug 23, 2017 at 1:29 AM, Jesper Dangaard Brouer
>>>>> <brouer@redhat.com> wrote:
>>>>>> On Tue, 22 Aug 2017 23:59:05 -0700
>>>>>> Michael Chan <michael.chan@broadcom.com> wrote:
>>>>>>
>>>>>>> On Tue, Aug 22, 2017 at 6:06 PM, Alexander Duyck
>>>>>>> <alexander.duyck@gmail.com> wrote:
>>>>>>>> On Tue, Aug 22, 2017 at 1:04 PM, Michael Chan <michael.chan@broadcom.com> wrote:
>>>>>>>>>
>>>>>>>>> Right, but it's conceivable to add an API to "return" the buffer to
>>>>>>>>> the input device, right?
>>>>>>
>>>>>> Yes, I would really like to see an API like this.
>>>>>>
>>>>>>>>
>>>>>>>> You could, it is just added complexity. "just free the buffer" in
>>>>>>>> ixgbe usually just amounts to one atomic operation to decrement the
>>>>>>>> total page count since page recycling is already implemented in the
>>>>>>>> driver. You still would have to unmap the buffer regardless of if you
>>>>>>>> were recycling it or not so all you would save is 1.000015259 atomic
>>>>>>>> operations per packet. The fraction is because once every 64K uses we
>>>>>>>> have to bulk update the count on the page.
>>>>>>>>
>>>>>>>
>>>>>>> If the buffer is returned to the input device, the input device can
>>>>>>> keep the DMA mapping. All it needs to do is to dma_sync it back to
>>>>>>> the input device when the buffer is returned.
>>>>>>
>>>>>> Yes, exactly, return to the input device. I really think we should
>>>>>> work on a solution where we can keep the DMA mapping around. We have
>>>>>> an opportunity here to make ndo_xdp_xmit TX queues use a specialized
>>>>>> page return call, to achieve this. (I imagine other arch's have a high
>>>>>> DMA overhead than Intel)
>>>>>>
>>>>>> I'm not sure how the API should look. The ixgbe recycle mechanism and
>>>>>> splitting the page (into two packets) actually complicates things, and
>>>>>> tie us into a page-refcnt based model. We could get around this by
>>>>>> each driver implementing a page-return-callback, that allow us to
>>>>>> return the page to the input device? Then, drivers implementing the
>>>>>> 1-packet-per-page can simply check/read the page-refcnt, and if it is
>>>>>> "1" DMA-sync and reuse it in the RX queue.
>>>>>>
>>>>>
>>>>> Yeah, based on Alex' description, it's not clear to me whether ixgbe
>>>>> redirecting to a non-intel NIC or vice versa will actually work. It
>>>>> sounds like the output device has to make some assumptions about how
>>>>> the page was allocated by the input device.
>>>>
>>>> Yes, exactly. We are tied into a page refcnt based scheme.
>>>>
>>>> Besides the ixgbe page recycle scheme (which keeps the DMA RX-mapping)
>>>> is also tied to the RX queue size, plus how fast the pages are returned.
>>>> This makes it very hard to tune. As I demonstrated, default ixgbe
>>>> settings does not work well with XDP_REDIRECT. I needed to increase
>>>> TX-ring size, but it broke page recycling (dropping perf from 13Mpps to
>>>> 10Mpps) so I also needed it increase RX-ring size. But perf is best if
>>>> RX-ring size is smaller, thus two contradicting tuning needed.
>>>>
>>>
>>> The changes to decouple the ixgbe page recycle scheme (1pg per descriptor
>>> split into two halves being the default) from the number of descriptors
>>> doesn't look too bad IMO. It seems like it could be done by having some
>>> extra pages allocated upfront and pulling those in when we need another
>>> page.
>>>
>>> This would be a nice iterative step we could take on the existing API.
>>>
>>>>
>>>>> With buffer return API,
>>>>> each driver can cleanly recycle or free its own buffers properly.
>>>>
>>>> Yes, exactly. And RX-driver can implement a special memory model for
>>>> this queue. E.g. RX-driver can know this is a dedicated XDP RX-queue
>>>> which is never used for SKBs, thus opening for new RX memory models.
>>>>
>>>> Another advantage of a return API. There is also an opportunity for
>>>> avoiding the DMA map on TX. As we need to know the from-device. Thus,
>>>> we can add a DMA API, where we can query if the two devices uses the
>>>> same DMA engine, and can reuse the same DMA address the RX-side already
>>>> knows.
>>>>
>>>>
>>>>> Let me discuss this further with Andy to see if we can come up with a
>>>>> good scheme.
>>>>
>>>> Sound good, looking forward to hear what you come-up with :-)
>>>>
>>>
>>> I guess by this thread we will see a broadcom nic with redirect support
>>> soon ;)
>>
>> Yes, Andy actually has finished the coding for XDP_REDIRECT, but the
>> buffer recycling scheme has some problems. We can make it work for
>> Broadcom to Broadcom only, but we want a better solution.
>
> (Sorry for the radio silence I was AFK last week...)
>
> I finished it a little while ago, but Michael and I both have concerns
> that in a heterogenous hardware setup one can quickly run into issues
> and haven't had time to work-up a few solutions before bringing this up
> formally. It also isn't a major problem until the second
> optimized/native XDP driver appears on the scene.
>
> I can run a test where XDP redirects from an ixgbe <-> bnxt_en based
> device I get OOM kills after only a few seconds, due to the lack of
> feedback between the different drivers that the pointer to xdp->data can
> be freed/reused/etc and the different buffer allocation schemes used.
>
hmm so how do you get OOM here, I expect the number of in-flight xdp
bufs should be limited by the number of xdps that can be posted to the
outgoing interface. If we are hitting OOM that _should_ mean the size of
the tx queue is too large. Ixgbe should be free'ing the buffer if an error
is returned from xdp xmit routines (will check this today). And bnxt should
return an error if we hit some high water mark on xmit.
> Initially I did not think this was an issue and that xdp_do_flush_map()
> would handle this, but I think there is a still a need to be able to
> signal back to the receving device that the buffer allocated has been
> xmitted by the transmitter and can be freed. Since there is really no
> guarantee that completion of an XDP_REDIRECT action means that it is
> safe to free area pointed to by xdp->data area that contains the packet
> to be xmitted. Since the packet done interrupt handler in a driver
> cannot signal back the the receiving driver that the buffer is now safe
> to reuse/free there is a chance for trouble.
There should be some high water mark on how many outstanding packets
can be in-flight. At the moment I assumed this was something related to
queue lengths a more explicit high water mark could added to the xmit path
and tracked in xdp infrastructure.
>
> I was hoping to spend some time this week cooking up a patch that just
> did not allow use of XDP_REDIRECT when the ifindex of the outgoing
> device did not match that of the device to which the XDP prog was
> attached, but that probably is not worth the trouble when we would just
> fix it for real. (It would also require some really terrible hacks to
> enforce this in the kernel when all that is being done is setting up a
> map that contains the redirect table, so it is probably not useful.)
>
I would prefer to solve the problem vs limiting the implementation
> The basic prototype would be something like this:
>
> (rx packet interrupt on eth0, leads to napi_poll)
> napi_poll (eth0)
> call xdp_prog (eth0)
> xdp_do_redirect (eth0)
> ndo_xdp_xmit (eth1)
> mark buffer with information netdev/ring/etc
> place buffer on tx ring for eth1
>
> (tx done interrupt on eth1, leads to napi_poll)
> napi_poll (eth1)
> process tx interrupt (eth1)
> look up information about netdev/ring/etc
> ndo_xdp_data_free (eth0, ring, etc)
>
> Thoughts?
>
^ permalink raw reply
* Re: XDP redirect measurements, gotchas and tracepoints
From: Alexander Duyck @ 2017-08-28 16:11 UTC (permalink / raw)
To: Andy Gospodarek
Cc: Michael Chan, John Fastabend, Jesper Dangaard Brouer,
Duyck, Alexander H, pstaszewski@itcare.pl, netdev@vger.kernel.org,
xdp-newbies@vger.kernel.org, borkmann@iogearbox.net
In-Reply-To: <20170828160237.GA70910@C02RW35GFVH8.dhcp.broadcom.net>
On Mon, Aug 28, 2017 at 9:02 AM, Andy Gospodarek <andy@greyhouse.net> wrote:
> On Fri, Aug 25, 2017 at 08:28:55AM -0700, Michael Chan wrote:
>> On Fri, Aug 25, 2017 at 8:10 AM, John Fastabend
>> <john.fastabend@gmail.com> wrote:
>> > On 08/25/2017 05:45 AM, Jesper Dangaard Brouer wrote:
>> >> On Thu, 24 Aug 2017 20:36:28 -0700
>> >> Michael Chan <michael.chan@broadcom.com> wrote:
>> >>
>> >>> On Wed, Aug 23, 2017 at 1:29 AM, Jesper Dangaard Brouer
>> >>> <brouer@redhat.com> wrote:
>> >>>> On Tue, 22 Aug 2017 23:59:05 -0700
>> >>>> Michael Chan <michael.chan@broadcom.com> wrote:
>> >>>>
>> >>>>> On Tue, Aug 22, 2017 at 6:06 PM, Alexander Duyck
>> >>>>> <alexander.duyck@gmail.com> wrote:
>> >>>>>> On Tue, Aug 22, 2017 at 1:04 PM, Michael Chan <michael.chan@broadcom.com> wrote:
>> >>>>>>>
>> >>>>>>> Right, but it's conceivable to add an API to "return" the buffer to
>> >>>>>>> the input device, right?
>> >>>>
>> >>>> Yes, I would really like to see an API like this.
>> >>>>
>> >>>>>>
>> >>>>>> You could, it is just added complexity. "just free the buffer" in
>> >>>>>> ixgbe usually just amounts to one atomic operation to decrement the
>> >>>>>> total page count since page recycling is already implemented in the
>> >>>>>> driver. You still would have to unmap the buffer regardless of if you
>> >>>>>> were recycling it or not so all you would save is 1.000015259 atomic
>> >>>>>> operations per packet. The fraction is because once every 64K uses we
>> >>>>>> have to bulk update the count on the page.
>> >>>>>>
>> >>>>>
>> >>>>> If the buffer is returned to the input device, the input device can
>> >>>>> keep the DMA mapping. All it needs to do is to dma_sync it back to
>> >>>>> the input device when the buffer is returned.
>> >>>>
>> >>>> Yes, exactly, return to the input device. I really think we should
>> >>>> work on a solution where we can keep the DMA mapping around. We have
>> >>>> an opportunity here to make ndo_xdp_xmit TX queues use a specialized
>> >>>> page return call, to achieve this. (I imagine other arch's have a high
>> >>>> DMA overhead than Intel)
>> >>>>
>> >>>> I'm not sure how the API should look. The ixgbe recycle mechanism and
>> >>>> splitting the page (into two packets) actually complicates things, and
>> >>>> tie us into a page-refcnt based model. We could get around this by
>> >>>> each driver implementing a page-return-callback, that allow us to
>> >>>> return the page to the input device? Then, drivers implementing the
>> >>>> 1-packet-per-page can simply check/read the page-refcnt, and if it is
>> >>>> "1" DMA-sync and reuse it in the RX queue.
>> >>>>
>> >>>
>> >>> Yeah, based on Alex' description, it's not clear to me whether ixgbe
>> >>> redirecting to a non-intel NIC or vice versa will actually work. It
>> >>> sounds like the output device has to make some assumptions about how
>> >>> the page was allocated by the input device.
>> >>
>> >> Yes, exactly. We are tied into a page refcnt based scheme.
>> >>
>> >> Besides the ixgbe page recycle scheme (which keeps the DMA RX-mapping)
>> >> is also tied to the RX queue size, plus how fast the pages are returned.
>> >> This makes it very hard to tune. As I demonstrated, default ixgbe
>> >> settings does not work well with XDP_REDIRECT. I needed to increase
>> >> TX-ring size, but it broke page recycling (dropping perf from 13Mpps to
>> >> 10Mpps) so I also needed it increase RX-ring size. But perf is best if
>> >> RX-ring size is smaller, thus two contradicting tuning needed.
>> >>
>> >
>> > The changes to decouple the ixgbe page recycle scheme (1pg per descriptor
>> > split into two halves being the default) from the number of descriptors
>> > doesn't look too bad IMO. It seems like it could be done by having some
>> > extra pages allocated upfront and pulling those in when we need another
>> > page.
>> >
>> > This would be a nice iterative step we could take on the existing API.
>> >
>> >>
>> >>> With buffer return API,
>> >>> each driver can cleanly recycle or free its own buffers properly.
>> >>
>> >> Yes, exactly. And RX-driver can implement a special memory model for
>> >> this queue. E.g. RX-driver can know this is a dedicated XDP RX-queue
>> >> which is never used for SKBs, thus opening for new RX memory models.
>> >>
>> >> Another advantage of a return API. There is also an opportunity for
>> >> avoiding the DMA map on TX. As we need to know the from-device. Thus,
>> >> we can add a DMA API, where we can query if the two devices uses the
>> >> same DMA engine, and can reuse the same DMA address the RX-side already
>> >> knows.
>> >>
>> >>
>> >>> Let me discuss this further with Andy to see if we can come up with a
>> >>> good scheme.
>> >>
>> >> Sound good, looking forward to hear what you come-up with :-)
>> >>
>> >
>> > I guess by this thread we will see a broadcom nic with redirect support
>> > soon ;)
>>
>> Yes, Andy actually has finished the coding for XDP_REDIRECT, but the
>> buffer recycling scheme has some problems. We can make it work for
>> Broadcom to Broadcom only, but we want a better solution.
>
> (Sorry for the radio silence I was AFK last week...)
>
> I finished it a little while ago, but Michael and I both have concerns
> that in a heterogenous hardware setup one can quickly run into issues
> and haven't had time to work-up a few solutions before bringing this up
> formally. It also isn't a major problem until the second
> optimized/native XDP driver appears on the scene.
>
> I can run a test where XDP redirects from an ixgbe <-> bnxt_en based
> device I get OOM kills after only a few seconds, due to the lack of
> feedback between the different drivers that the pointer to xdp->data can
> be freed/reused/etc and the different buffer allocation schemes used.
>
> Initially I did not think this was an issue and that xdp_do_flush_map()
> would handle this, but I think there is a still a need to be able to
> signal back to the receving device that the buffer allocated has been
> xmitted by the transmitter and can be freed. Since there is really no
> guarantee that completion of an XDP_REDIRECT action means that it is
> safe to free area pointed to by xdp->data area that contains the packet
> to be xmitted. Since the packet done interrupt handler in a driver
> cannot signal back the the receiving driver that the buffer is now safe
> to reuse/free there is a chance for trouble.
>
> I was hoping to spend some time this week cooking up a patch that just
> did not allow use of XDP_REDIRECT when the ifindex of the outgoing
> device did not match that of the device to which the XDP prog was
> attached, but that probably is not worth the trouble when we would just
> fix it for real. (It would also require some really terrible hacks to
> enforce this in the kernel when all that is being done is setting up a
> map that contains the redirect table, so it is probably not useful.)
>
> The basic prototype would be something like this:
>
> (rx packet interrupt on eth0, leads to napi_poll)
> napi_poll (eth0)
> call xdp_prog (eth0)
> xdp_do_redirect (eth0)
> ndo_xdp_xmit (eth1)
> mark buffer with information netdev/ring/etc
> place buffer on tx ring for eth1
>
> (tx done interrupt on eth1, leads to napi_poll)
> napi_poll (eth1)
> process tx interrupt (eth1)
> look up information about netdev/ring/etc
> ndo_xdp_data_free (eth0, ring, etc)
>
> Thoughts?
>
My advice would be to not over complicate this. My big concern with
all this buffer recycling is what happens the first time somebody
introduces something like mirroring? Are you going to copy the data to
a new page which would be quite expensive or just have to introduce
reference counts? You are going to have to deal with stuff like
reference counts eventually so you might as well bite that bullet now.
My advice would be to not bother with optimizing for performance right
now and instead focus on just getting functionality. The approach we
took in ixgbe for the transmit path should work for almost any other
driver since all you are looking at is having to free the page
reference which takes care of reference counting already.
- Alex
^ permalink raw reply
* Re: XDP redirect measurements, gotchas and tracepoints
From: Andy Gospodarek @ 2017-08-28 16:02 UTC (permalink / raw)
To: Michael Chan
Cc: John Fastabend, Jesper Dangaard Brouer, Alexander Duyck,
Duyck, Alexander H, pstaszewski@itcare.pl, netdev@vger.kernel.org,
xdp-newbies@vger.kernel.org, borkmann@iogearbox.net
In-Reply-To: <CACKFLin-sZEkkCxE2iZRHjgG=K36OJ65B-xrEYVCCSQqhYsH-g@mail.gmail.com>
On Fri, Aug 25, 2017 at 08:28:55AM -0700, Michael Chan wrote:
> On Fri, Aug 25, 2017 at 8:10 AM, John Fastabend
> <john.fastabend@gmail.com> wrote:
> > On 08/25/2017 05:45 AM, Jesper Dangaard Brouer wrote:
> >> On Thu, 24 Aug 2017 20:36:28 -0700
> >> Michael Chan <michael.chan@broadcom.com> wrote:
> >>
> >>> On Wed, Aug 23, 2017 at 1:29 AM, Jesper Dangaard Brouer
> >>> <brouer@redhat.com> wrote:
> >>>> On Tue, 22 Aug 2017 23:59:05 -0700
> >>>> Michael Chan <michael.chan@broadcom.com> wrote:
> >>>>
> >>>>> On Tue, Aug 22, 2017 at 6:06 PM, Alexander Duyck
> >>>>> <alexander.duyck@gmail.com> wrote:
> >>>>>> On Tue, Aug 22, 2017 at 1:04 PM, Michael Chan <michael.chan@broadcom.com> wrote:
> >>>>>>>
> >>>>>>> Right, but it's conceivable to add an API to "return" the buffer to
> >>>>>>> the input device, right?
> >>>>
> >>>> Yes, I would really like to see an API like this.
> >>>>
> >>>>>>
> >>>>>> You could, it is just added complexity. "just free the buffer" in
> >>>>>> ixgbe usually just amounts to one atomic operation to decrement the
> >>>>>> total page count since page recycling is already implemented in the
> >>>>>> driver. You still would have to unmap the buffer regardless of if you
> >>>>>> were recycling it or not so all you would save is 1.000015259 atomic
> >>>>>> operations per packet. The fraction is because once every 64K uses we
> >>>>>> have to bulk update the count on the page.
> >>>>>>
> >>>>>
> >>>>> If the buffer is returned to the input device, the input device can
> >>>>> keep the DMA mapping. All it needs to do is to dma_sync it back to
> >>>>> the input device when the buffer is returned.
> >>>>
> >>>> Yes, exactly, return to the input device. I really think we should
> >>>> work on a solution where we can keep the DMA mapping around. We have
> >>>> an opportunity here to make ndo_xdp_xmit TX queues use a specialized
> >>>> page return call, to achieve this. (I imagine other arch's have a high
> >>>> DMA overhead than Intel)
> >>>>
> >>>> I'm not sure how the API should look. The ixgbe recycle mechanism and
> >>>> splitting the page (into two packets) actually complicates things, and
> >>>> tie us into a page-refcnt based model. We could get around this by
> >>>> each driver implementing a page-return-callback, that allow us to
> >>>> return the page to the input device? Then, drivers implementing the
> >>>> 1-packet-per-page can simply check/read the page-refcnt, and if it is
> >>>> "1" DMA-sync and reuse it in the RX queue.
> >>>>
> >>>
> >>> Yeah, based on Alex' description, it's not clear to me whether ixgbe
> >>> redirecting to a non-intel NIC or vice versa will actually work. It
> >>> sounds like the output device has to make some assumptions about how
> >>> the page was allocated by the input device.
> >>
> >> Yes, exactly. We are tied into a page refcnt based scheme.
> >>
> >> Besides the ixgbe page recycle scheme (which keeps the DMA RX-mapping)
> >> is also tied to the RX queue size, plus how fast the pages are returned.
> >> This makes it very hard to tune. As I demonstrated, default ixgbe
> >> settings does not work well with XDP_REDIRECT. I needed to increase
> >> TX-ring size, but it broke page recycling (dropping perf from 13Mpps to
> >> 10Mpps) so I also needed it increase RX-ring size. But perf is best if
> >> RX-ring size is smaller, thus two contradicting tuning needed.
> >>
> >
> > The changes to decouple the ixgbe page recycle scheme (1pg per descriptor
> > split into two halves being the default) from the number of descriptors
> > doesn't look too bad IMO. It seems like it could be done by having some
> > extra pages allocated upfront and pulling those in when we need another
> > page.
> >
> > This would be a nice iterative step we could take on the existing API.
> >
> >>
> >>> With buffer return API,
> >>> each driver can cleanly recycle or free its own buffers properly.
> >>
> >> Yes, exactly. And RX-driver can implement a special memory model for
> >> this queue. E.g. RX-driver can know this is a dedicated XDP RX-queue
> >> which is never used for SKBs, thus opening for new RX memory models.
> >>
> >> Another advantage of a return API. There is also an opportunity for
> >> avoiding the DMA map on TX. As we need to know the from-device. Thus,
> >> we can add a DMA API, where we can query if the two devices uses the
> >> same DMA engine, and can reuse the same DMA address the RX-side already
> >> knows.
> >>
> >>
> >>> Let me discuss this further with Andy to see if we can come up with a
> >>> good scheme.
> >>
> >> Sound good, looking forward to hear what you come-up with :-)
> >>
> >
> > I guess by this thread we will see a broadcom nic with redirect support
> > soon ;)
>
> Yes, Andy actually has finished the coding for XDP_REDIRECT, but the
> buffer recycling scheme has some problems. We can make it work for
> Broadcom to Broadcom only, but we want a better solution.
(Sorry for the radio silence I was AFK last week...)
I finished it a little while ago, but Michael and I both have concerns
that in a heterogenous hardware setup one can quickly run into issues
and haven't had time to work-up a few solutions before bringing this up
formally. It also isn't a major problem until the second
optimized/native XDP driver appears on the scene.
I can run a test where XDP redirects from an ixgbe <-> bnxt_en based
device I get OOM kills after only a few seconds, due to the lack of
feedback between the different drivers that the pointer to xdp->data can
be freed/reused/etc and the different buffer allocation schemes used.
Initially I did not think this was an issue and that xdp_do_flush_map()
would handle this, but I think there is a still a need to be able to
signal back to the receving device that the buffer allocated has been
xmitted by the transmitter and can be freed. Since there is really no
guarantee that completion of an XDP_REDIRECT action means that it is
safe to free area pointed to by xdp->data area that contains the packet
to be xmitted. Since the packet done interrupt handler in a driver
cannot signal back the the receiving driver that the buffer is now safe
to reuse/free there is a chance for trouble.
I was hoping to spend some time this week cooking up a patch that just
did not allow use of XDP_REDIRECT when the ifindex of the outgoing
device did not match that of the device to which the XDP prog was
attached, but that probably is not worth the trouble when we would just
fix it for real. (It would also require some really terrible hacks to
enforce this in the kernel when all that is being done is setting up a
map that contains the redirect table, so it is probably not useful.)
The basic prototype would be something like this:
(rx packet interrupt on eth0, leads to napi_poll)
napi_poll (eth0)
call xdp_prog (eth0)
xdp_do_redirect (eth0)
ndo_xdp_xmit (eth1)
mark buffer with information netdev/ring/etc
place buffer on tx ring for eth1
(tx done interrupt on eth1, leads to napi_poll)
napi_poll (eth1)
process tx interrupt (eth1)
look up information about netdev/ring/etc
ndo_xdp_data_free (eth0, ring, etc)
Thoughts?
^ permalink raw reply
* Re: [PATCH net-next] bpf: fix oops on allocation failure
From: John Fastabend @ 2017-08-28 15:58 UTC (permalink / raw)
To: Daniel Borkmann, Dan Carpenter, Alexei Starovoitov
Cc: netdev, kernel-janitors
In-Reply-To: <59A08CCD.2050603@iogearbox.net>
On 08/25/2017 01:47 PM, Daniel Borkmann wrote:
> On 08/25/2017 10:27 PM, Dan Carpenter wrote:
>> "err" is set to zero if bpf_map_area_alloc() fails so it means we return
>> ERR_PTR(0) which is NULL. The caller, find_and_alloc_map(), is not
>> expecting NULL returns and will oops.
>>
>> Fixes: 174a79ff9515 ("bpf: sockmap with sk redirect support")
>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Thanks.
Acked-by: John Fastabend <john.fastabend@gmail.com>
^ permalink raw reply
* [PATCH net v1 1/1] tipc: permit bond slave as bearer
From: Parthasarathy Bhuvaragan @ 2017-08-28 15:57 UTC (permalink / raw)
To: davem; +Cc: netdev, tipc-discussion, jon.maloy, maloy, ying.xue
For a bond slave device as a tipc bearer, the dev represents the bond
interface and orig_dev represents the slave in tipc_l2_rcv_msg().
Since we decode the tipc_ptr from bonding device (dev), we fail to
find the bearer and thus tipc links are not established.
In this commit, we register the tipc protocol callback per device and
look for tipc bearer from both the devices.
Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
---
net/tipc/bearer.c | 26 +++++++++++---------------
net/tipc/bearer.h | 2 ++
2 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/net/tipc/bearer.c b/net/tipc/bearer.c
index 767e0537dde5..89cd061c4468 100644
--- a/net/tipc/bearer.c
+++ b/net/tipc/bearer.c
@@ -65,6 +65,8 @@ static struct tipc_bearer *bearer_get(struct net *net, int bearer_id)
}
static void bearer_disable(struct net *net, struct tipc_bearer *b);
+static int tipc_l2_rcv_msg(struct sk_buff *skb, struct net_device *dev,
+ struct packet_type *pt, struct net_device *orig_dev);
/**
* tipc_media_find - locates specified media object by name
@@ -428,6 +430,10 @@ int tipc_enable_l2_media(struct net *net, struct tipc_bearer *b,
/* Associate TIPC bearer with L2 bearer */
rcu_assign_pointer(b->media_ptr, dev);
+ b->pt.dev = dev;
+ b->pt.type = htons(ETH_P_TIPC);
+ b->pt.func = tipc_l2_rcv_msg;
+ dev_add_pack(&b->pt);
memset(&b->bcast_addr, 0, sizeof(b->bcast_addr));
memcpy(b->bcast_addr.value, dev->broadcast, b->media->hwaddr_len);
b->bcast_addr.media_id = b->media->type_id;
@@ -447,6 +453,7 @@ void tipc_disable_l2_media(struct tipc_bearer *b)
struct net_device *dev;
dev = (struct net_device *)rtnl_dereference(b->media_ptr);
+ dev_remove_pack(&b->pt);
RCU_INIT_POINTER(dev->tipc_ptr, NULL);
synchronize_net();
dev_put(dev);
@@ -594,11 +601,12 @@ static int tipc_l2_rcv_msg(struct sk_buff *skb, struct net_device *dev,
struct tipc_bearer *b;
rcu_read_lock();
- b = rcu_dereference_rtnl(dev->tipc_ptr);
+ b = rcu_dereference_rtnl(dev->tipc_ptr) ?:
+ rcu_dereference_rtnl(orig_dev->tipc_ptr);
if (likely(b && test_bit(0, &b->up) &&
(skb->pkt_type <= PACKET_MULTICAST))) {
skb->next = NULL;
- tipc_rcv(dev_net(dev), skb, b);
+ tipc_rcv(dev_net(b->pt.dev), skb, b);
rcu_read_unlock();
return NET_RX_SUCCESS;
}
@@ -659,11 +667,6 @@ static int tipc_l2_device_event(struct notifier_block *nb, unsigned long evt,
return NOTIFY_OK;
}
-static struct packet_type tipc_packet_type __read_mostly = {
- .type = htons(ETH_P_TIPC),
- .func = tipc_l2_rcv_msg,
-};
-
static struct notifier_block notifier = {
.notifier_call = tipc_l2_device_event,
.priority = 0,
@@ -671,19 +674,12 @@ static struct notifier_block notifier = {
int tipc_bearer_setup(void)
{
- int err;
-
- err = register_netdevice_notifier(¬ifier);
- if (err)
- return err;
- dev_add_pack(&tipc_packet_type);
- return 0;
+ return register_netdevice_notifier(¬ifier);
}
void tipc_bearer_cleanup(void)
{
unregister_netdevice_notifier(¬ifier);
- dev_remove_pack(&tipc_packet_type);
}
void tipc_bearer_stop(struct net *net)
diff --git a/net/tipc/bearer.h b/net/tipc/bearer.h
index 635c9086e19a..e07a55a80c18 100644
--- a/net/tipc/bearer.h
+++ b/net/tipc/bearer.h
@@ -131,6 +131,7 @@ struct tipc_media {
* @name: bearer name (format = media:interface)
* @media: ptr to media structure associated with bearer
* @bcast_addr: media address used in broadcasting
+ * @pt: packet type for bearer
* @rcu: rcu struct for tipc_bearer
* @priority: default link priority for bearer
* @window: default window size for bearer
@@ -151,6 +152,7 @@ struct tipc_bearer {
char name[TIPC_MAX_BEARER_NAME];
struct tipc_media *media;
struct tipc_media_addr bcast_addr;
+ struct packet_type pt;
struct rcu_head rcu;
u32 priority;
u32 window;
--
2.1.4
^ permalink raw reply related
* Re: mlxsw and rtnl lock
From: Roopa Prabhu @ 2017-08-28 15:55 UTC (permalink / raw)
To: Ido Schimmel; +Cc: David Ahern, Jiri Pirko, netdev@vger.kernel.org, mlxsw
In-Reply-To: <20170826170418.GA22324@shredder>
On Sat, Aug 26, 2017 at 10:04 AM, Ido Schimmel <idosch@idosch.org> wrote:
> On Fri, Aug 25, 2017 at 01:26:07PM -0700, David Ahern wrote:
>> Jiri / Ido:
>>
>>
[snip]
>
> Regarding the silent abort, that's intentional. You can look at the same
> code in v4.9 - when the chain was still blocking - and you'll see that
> we didn't propagate the error even then. This was discussed in the past
> and the conclusion was that user doesn't expect to operation to fail. If
> hardware resources are exceeded, we let the kernel take care of the
> forwarding instead.
History here is that the initial fib offload hooks were added during
rocker days.
subsequently we have had many discussions (on offload policies) to see
if we can remove that
check and report the error back to the user (routing daemon in this
case) since the cpu kernel
cannot handle 100G or more traffic on such platforms. Basically the
cpu kernel cannot take care
of forwarding for such platforms. I believe this came up during the
last switchdev BOF as well.
The current silent abort is in there because kernel needs to maintain
its semantics for hardware offload.
Which is a valid position but we will need to find a way to make it
work for switch platforms.
IIUC, the only place where switchdev offload returns error to the user is
'bridge and bond membership offload'
I know fib and bridge fdb offload don't propagate errors to the user
(maybe they used to before moving to notifiers ?. need to check
history on this).
Are tc hardware offload errors propagated to the user ?
It is a bit inconsistent today, some errors are propagated to the user
and some are not.
^ permalink raw reply
* Re: [PATCH net-next 1/4] net: Add SRIOV VGT+ support
From: Sabrina Dubroca @ 2017-08-28 15:52 UTC (permalink / raw)
To: Saeed Mahameed
Cc: David S. Miller, netdev, Eugenia Emantayev, Mohamad Haj Yahia,
Hannes Frederic Sowa
In-Reply-To: <20170827110618.20599-2-saeedm@mellanox.com>
2017-08-27, 14:06:15 +0300, Saeed Mahameed wrote:
[...]
> +#define VF_VLAN_BITMAP DIV_ROUND_UP(VF_VLAN_N_VID, sizeof(__u64) * BITS_PER_BYTE)
> +struct ifla_vf_vlan_trunk {
> + __u32 vf;
> + __u64 allowed_vlans_8021q_bm[VF_VLAN_BITMAP];
> + __u64 allowed_vlans_8021ad_bm[VF_VLAN_BITMAP];
> +};
This is huge (1032B). And you put one of these in the netlink message
for each VF. This means that with 51 VF (at least in my environment,
where each VF takes 1296B), you're going to overflow the u16 size of a
single attribute (IFLA_VFINFO_LIST), and you cannot dump the device
anymore. I'm afraid this is going to break existing setups.
--
Sabrina
^ permalink raw reply
* Fwd: DA850-evm MAC Address is random
From: Adam Ford @ 2017-08-28 15:32 UTC (permalink / raw)
To: grygorii.strashko, linux-omap, netdev
The davinvi_emac MAC address seems to attempt a call to
ti_cm_get_macid in cpsw-common.c but it returns the message
'davinci_emac davinci_emac.1: incompatible machine/device type for
reading mac address ' and then generates a random MAC address.
The function appears to lookup varions boards using
'of_machine_is_compaible' and supports dm8148, am33xx, am3517, dm816,
am4372 and dra7. I don't see the ti,davinci-dm6467-emac which is
what's shown in the da850 device tree.
Is there a patch somewhere for supporting the da850-evm?
If not, is there a way to pass the MAC address from U-Boot to the
driver so it doesn't generate a random MAC?
adam
^ permalink raw reply
* Re: [PATCH RFC WIP 0/5] IGMP snooping for local traffic
From: Stephen Hemminger @ 2017-08-28 15:11 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, Vivien Didelot, Florian Fainelli, nikolay, jiri, roopa,
bridge
In-Reply-To: <1503780970-10312-1-git-send-email-andrew@lunn.ch>
On Sat, 26 Aug 2017 22:56:05 +0200
Andrew Lunn <andrew@lunn.ch> wrote:
> This is a WIP patchset i would like comments on from bridge, switchdev
> and hardware offload people.
>
> The linux bridge supports IGMP snooping. It will listen to IGMP
> reports on bridge ports and keep track of which groups have been
> joined on an interface. It will then forward multicast based on this
> group membership.
>
> When the bridge adds or removed groups from an interface, it uses
> switchdev to request the hardware add an mdb to a port, so the
> hardware can perform the selective forwarding between ports.
>
> What is not covered by the current bridge code, is IGMP joins/leaves
> from the host on the brX interface. No such monitoring is
> performed. With a pure software bridge, it is not required. All
> mulitcast frames are passed to the brX interface, and the network
> stack filters them, as it does for any interface. However, when
> hardware offload is involved, things change. We should program the
> hardware to only send multcast packets to the host when the host has
> in interest in them.
>
> Thus we need to perform IGMP snooping on the brX interface, just like
> any other interface of the bridge. However, currently the brX
> interface is missing all the needed data structures to do this. There
> is no net_bridge_port structure for the brX interface. This strucuture
> is created when an interface is added to the bridge. But the brX
> interface is not a member of the bridge. So this patchset makes the
> brX interface a first class member of the bridge. When the brX
> interface is opened, the interface is added to the bridge. A
> net_bridge_port is allocated for it, and IGMP snooping is performed as
> usual.
>
> There are some complexities here. Some assumptions are broken, like
> the master interface of a port interface is the bridge interface. The
> brX interface cannot be its own master. The use of
> netdev_master_upper_dev_get() within the bridge code has been changed
> to reflecit this. The bridge receive handler needs to not process
> frames for the brX interface, etc.
>
> The interface downward to the hardware is also an issue. The code
> presented here is a hack and needs to change. But that is secondary
> and can be solved once it is agreed how the bridge needs to change to
> support this use case.
>
> Comment welcome and wanted.
>
> Andrew
>
> Andrew Lunn (5):
> net: rtnetlink: Handle bridge port without upper device
> net: bridge: Skip receive handler on brX interface
> net: bridge: Make the brX interface a member of the bridge
> net: dsa: HACK: Handle MDB add/remove for none-switch ports
> net: dsa: Don't include CPU port when adding MDB to a port
>
> include/linux/if_bridge.h | 1 +
> net/bridge/br_device.c | 12 ++++++++++--
> net/bridge/br_if.c | 37 ++++++++++++++++++++++++-------------
> net/bridge/br_input.c | 4 ++++
> net/bridge/br_mdb.c | 2 --
> net/bridge/br_multicast.c | 7 ++++---
> net/bridge/br_private.h | 1 +
> net/core/rtnetlink.c | 23 +++++++++++++++++++++--
> net/dsa/port.c | 19 +++++++++++++++++--
> net/dsa/switch.c | 2 +-
> 10 files changed, 83 insertions(+), 25 deletions(-)
>
Sorry you can't change the semantics of the bridge like this.
There are likely to be scripts and management utilities that won't work after this.
Figure out another way. Such as adding IGMP updates in the local packet send/receive path.
^ permalink raw reply
* Re: IPv6 loopback issue report
From: David Ahern @ 2017-08-28 15:07 UTC (permalink / raw)
To: Tariq Toukan, Linux Kernel Network Developers, David Miller,
Alexey Kuznetsov, Hideaki YOSHIFUJI
Cc: ranro, guye, Eran Ben Elisha
In-Reply-To: <464e900f-c256-4d22-6a83-a3aea0fca8bc@mellanox.com>
On 8/28/17 8:48 AM, Tariq Toukan wrote:
> # /bin/ping6 -c 3 fe80::7efe:90ff:fecb:7502%ens8
> PING fe80::7efe:90ff:fecb:7502%ens8(fe80::7efe:90ff:fecb:7502) 56 data
> bytes
>
> --- fe80::7efe:90ff:fecb:7502%ens8 ping statistics ---
> 3 packets transmitted, 0 received, 100% packet loss, time 2043ms
I'll take a look. Most likely related to my recent IPv6 change.
^ permalink raw reply
* Re: [PATCH net-next] bridge: fdb add and delete tracepoints
From: Roopa Prabhu @ 2017-08-28 15:03 UTC (permalink / raw)
To: Florian Fainelli
Cc: Nikolay Aleksandrov, netdev@vger.kernel.org, bridge,
davem@davemloft.net, Andrew Lunn
In-Reply-To: <592631a3-6a80-407a-f087-37f7f04417d2@gmail.com>
On Sun, Aug 27, 2017 at 7:11 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 08/27/2017 02:33 PM, Roopa Prabhu wrote:
>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>
>> Tracepoints to trace bridge forwarding database updates.
>
> Thanks for adding this!
>
>>
>> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>> ---
>> include/trace/events/bridge.h | 98 +++++++++++++++++++++++++++++++++++++++++++
>> net/bridge/br_fdb.c | 7 ++++
>> net/core/net-traces.c | 6 +++
>> 3 files changed, 111 insertions(+)
>> create mode 100644 include/trace/events/bridge.h
>>
>> diff --git a/include/trace/events/bridge.h b/include/trace/events/bridge.h
>> new file mode 100644
>> index 0000000..e2d52cf
>> --- /dev/null
>> +++ b/include/trace/events/bridge.h
>> @@ -0,0 +1,98 @@
>> +#undef TRACE_SYSTEM
>> +#define TRACE_SYSTEM bridge
>> +
>> +#if !defined(_TRACE_BRIDGE_H) || defined(TRACE_HEADER_MULTI_READ)
>> +#define _TRACE_BRIDGE_H
>> +
>> +#include <linux/netdevice.h>
>> +#include <linux/tracepoint.h>
>> +
>> +#include "../../../net/bridge/br_private.h"
>> +
>> +TRACE_EVENT(br_fdb_add,
>> +
>> + TP_PROTO(struct ndmsg *ndm, struct net_device *dev,
>> + const unsigned char *addr, u16 vid, u16 nlh_flags),
>> +
>> + TP_ARGS(ndm, dev, addr, vid, nlh_flags),
>> +
>> + TP_STRUCT__entry(
>> + __field(u8, ndm_flags)
>> + __string(dev, dev->name)
>> + __array(unsigned char, addr, 6)
>
> Can you use ETH_ALEN instead of 6 here?
>
>> + __field(u16, vid)
>> + __field(u16, nlh_flags)
>> + ),
>> +
>> + TP_fast_assign(
>> + __assign_str(dev, dev->name);
>> + memcpy(__entry->addr, addr, 6);
>
> Likewise
>
>> + __entry->vid = vid;
>> + __entry->nlh_flags = nlh_flags;
>> + __entry->ndm_flags = ndm->ndm_flags;
>> + ),
>> +
>> + TP_printk("dev %s addr %02x:%02x:%02x:%02x:%02x:%02x vid %u nlh_flags %x ndm_flags = %x",
>
> I wonder if we could make %pM work for TP_printk() as this would
> simplify the argument list a bitt. Can you use %04x for vid, nlh_flags
> and %02x for ndm_flags?
one thing here.., i think %u is better for vid. bridge driver debug
prints also use %u for vid.
^ permalink raw reply
* Re: [ethtool] ethtool: Remove UDP Fragmentation Offload use from ethtool
From: Eric Dumazet @ 2017-08-28 15:00 UTC (permalink / raw)
To: Tariq Toukan; +Cc: John W. Linville, netdev, Eran Ben Elisha, Shaker Daibes
In-Reply-To: <1503923928-9419-1-git-send-email-tariqt@mellanox.com>
On Mon, 2017-08-28 at 15:38 +0300, Tariq Toukan wrote:
> From: Shaker Daibes <shakerd@mellanox.com>
>
> UFO was removed in kernel, here we remove it in ethtool app.
>
> Fixes the following issue:
> Features for ens8:
> Cannot get device udp-fragmentation-offload settings: Operation not supported
>
> Tested with "make check"
>
> Signed-off-by: Shaker Daibes <shakerd@mellanox.com>
> Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
> ---
Hi guys
I would rather remove the warning, but leave the ability to switch UFO
on machines running old kernel but a recent ethtool.
ethtool does not need to be downgraded every time we boot an old
kernel ;)
Thanks !
^ permalink raw reply
* [PATCH net-next v3 13/13] arm64: defconfig: enable Marvell CP110 comphy
From: Antoine Tenart @ 2017-08-28 14:57 UTC (permalink / raw)
To: davem, kishon, andrew, jason, sebastian.hesselbarth,
gregory.clement
Cc: Miquel Raynal, thomas.petazzoni, nadavh, linux, linux-kernel, mw,
stefanc, netdev, Antoine Tenart
In-Reply-To: <20170828145725.2539-1-antoine.tenart@free-electrons.com>
From: Miquel Raynal <miquel.raynal@free-electrons.com>
The comphy is an hardware block giving access to common PHYs that can be
used by various other engines (Network, SATA, ...). This is used on
Marvell 7k/8k platforms for now. Enable the corresponding driver.
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 6b26a05ae5b4..d453ba50df43 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -510,6 +510,7 @@ CONFIG_PWM_TEGRA=m
CONFIG_PHY_RCAR_GEN3_USB2=y
CONFIG_PHY_HI6220_USB=y
CONFIG_PHY_SUN4I_USB=y
+CONFIG_PHY_MVEBU_CP110_COMPHY=y
CONFIG_PHY_ROCKCHIP_INNO_USB2=y
CONFIG_PHY_ROCKCHIP_EMMC=y
CONFIG_PHY_ROCKCHIP_PCIE=m
--
2.13.5
^ permalink raw reply related
* [PATCH net-next v3 12/13] arm64: dts: marvell: 7040-db: add comphy references to Ethernet ports
From: Antoine Tenart @ 2017-08-28 14:57 UTC (permalink / raw)
To: davem, kishon, andrew, jason, sebastian.hesselbarth,
gregory.clement
Cc: Antoine Tenart, thomas.petazzoni, nadavh, linux, linux-kernel, mw,
stefanc, miquel.raynal, netdev
In-Reply-To: <20170828145725.2539-1-antoine.tenart@free-electrons.com>
This patch adds comphy phandles to the Ethernet ports in the 7040-db
device tree. The comphy is used to configure the serdes PHYs used by
these ports.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
arch/arm64/boot/dts/marvell/armada-7040-db.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-7040-db.dts b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
index 92c761c380d3..03d1c42d7c47 100644
--- a/arch/arm64/boot/dts/marvell/armada-7040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
@@ -180,6 +180,7 @@
status = "okay";
phy = <&phy0>;
phy-mode = "sgmii";
+ phys = <&cpm_comphy0 1>;
};
&cpm_eth2 {
--
2.13.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox