* Re: [PATCHv2 perf/core 2/2] tools lib bpf: Sync with samples/bpf/libbpf
From: Joe Stringer @ 2016-11-17 3:40 UTC (permalink / raw)
To: Wangnan (F); +Cc: LKML, netdev, ast, Daniel Borkmann, Arnaldo Carvalho de Melo
In-Reply-To: <582D2222.4060309@huawei.com>
On 16 November 2016 at 19:21, Wangnan (F) <wangnan0@huawei.com> wrote:
>
>
> On 2016/11/17 10:46, Joe Stringer wrote:
>>
>> On 16 November 2016 at 18:10, Wangnan (F) <wangnan0@huawei.com> wrote:
>>>
>>> I'm also working on improving bpf.c. Please have a look at:
>>>
>>> https://lkml.org/lkml/2016/11/14/1078
>>>
>>> Since bpf.c is simple, I think we can add more functions and fixes
>>> gradually, instead of a full copy.
>>>
>>> See my inline comment below.
>>
>> Ah, I missed this, my apologies. It looks like it will provide much of
>> what I need, I can reassess this patch with your series in mind.
>>
>> One comment though for your patch (I don't have the original thread to
>> respond to unfortunately): The map_pin and map_get functions in your
>> patch series can be used to pin progs too, so maybe there is a better
>> name? You'll see that this patch uses bpf_obj_{pin,get}() - although I
>> wouldn't want those to be confused with the libbpf.c objects so maybe
>> there's a clearer name that could be used.
>
>
> The full thread can be found:
>
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1272045.html
>
> (lkml.kernel.org is not working for me, sorry)
>
> In that patch set, bpf_map_pin/get is linked into perf hooks, so BPF script
> can pin a map to sysfs. I think this feature would be useful, but I don't
> have an example to show how to use it. I didn't provide program pinning/get
> interface because in perf hook they are not useful. After rethinking your
> suggestion now I think it is okay to provide bpf_obj_{pin,get} in bpf.c
> and export bpf_map_pin to perf hook. I'll adjust my own patch.
OK. For what it's worth, I also have a slightly higher level user of
this interface with a patch series for libbpf.[ch] that allows to you
pin a bpf_object * to the filesystem; The idea is that you pass it a
subpath, then it will make sure the BPF FS is mounted, then put your
programs and maps under, for example,
/sys/fs/bpf/$subpath/{maps,progs}/foo (where 'foo' is a symbol name
from your eBPF ELF). I also plan to post this soon, but it depends on
bpf_obj_pin() so will need your patch to go in first. I will submit it
when I can.
>>>> /*
>>>> @@ -53,24 +60,71 @@ static int sys_bpf(enum bpf_cmd cmd, union bpf_attr
>>>> *attr,
>>>> return syscall(__NR_bpf, cmd, attr, size);
>>>> }
>>>> -int bpf_create_map(enum bpf_map_type map_type, int key_size,
>>>> - int value_size, int max_entries)
>>>> +int bpf_create_map(enum bpf_map_type map_type, int key_size, int
>>>> value_size,
>>>> + int max_entries, int map_flags)
>>>> {
>>>> - union bpf_attr attr;
>>>> + union bpf_attr attr = {
>>>> + .map_type = map_type,
>>>> + .key_size = key_size,
>>>> + .value_size = value_size,
>>>> + .max_entries = max_entries,
>>>> + .map_flags = map_flags,
>>>> + };
>>>> - memset(&attr, '\0', sizeof(attr));
>>>> + return sys_bpf(BPF_MAP_CREATE, &attr, sizeof(attr));
>>>> +}
>>>>
>>>
>>> I lost map_flags in original bpf.c. Thanks to your patch. map_flags is
>>> useful
>>> when creating BPF_MAP_TYPE_PERCPU_HASH: BPF_F_NO_PREALLOC is meanful in
>>> this
>>> case.
>>
>> Do you want me to resubmit this piece as a separate patch or will you
>> address this?
>
>
> Please send it.
OK.
^ permalink raw reply
* Re: [PATCHv2 perf/core 2/2] tools lib bpf: Sync with samples/bpf/libbpf
From: Wangnan (F) @ 2016-11-17 3:39 UTC (permalink / raw)
To: Joe Stringer; +Cc: LKML, netdev, ast, daniel, acme
In-Reply-To: <CAOftzPhXk0LKCt8wQKuqeBnDrj6a4p0YL7P80jhK78eFSAz8WQ@mail.gmail.com>
On 2016/11/17 10:46, Joe Stringer wrote:
> On 16 November 2016 at 18:10, Wangnan (F) <wangnan0@huawei.com> wrote:
>> I'm also working on improving bpf.c. Please have a look at:
>>
>> https://lkml.org/lkml/2016/11/14/1078
>>
>> Since bpf.c is simple, I think we can add more functions and fixes
>> gradually, instead of a full copy.
>>
>> See my inline comment below.
> Ah, I missed this, my apologies. It looks like it will provide much of
> what I need, I can reassess this patch with your series in mind.
>
> One comment though for your patch (I don't have the original thread to
> respond to unfortunately): The map_pin and map_get functions in your
> patch series can be used to pin progs too, so maybe there is a better
> name? You'll see that this patch uses bpf_obj_{pin,get}() - although I
> wouldn't want those to be confused with the libbpf.c objects so maybe
> there's a clearer name that could be used.
>
> I also have some patches to rework the samples/bpf/* code to use
> libbpf instead of the sample code that is there, is it worth me
> submitting that? It will need to wait for your patch to go in, plus a
> merge with davem's tree.
>
I'm happy to see you are trying to replace samples/bpf 's own
libbpf with tools/lib/bpf. I think you can submit your work
on libbpf and patches on samples together if they are ready.
Arnaldo can pick up patches good for him, and you can improve
other patches based on his newest branch.
Thank you.
^ permalink raw reply
* RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable
From: Hayes Wang @ 2016-11-17 3:36 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: nic_swsd, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
mlord@pobox.com
In-Reply-To: <1394712342-15778-227-Taiwan-albertk@realtek.com>
[...]
> Fix the hw rx checksum is always enabled, and the user couldn't switch
> it to sw rx checksum.
>
> Note that the RTL_VER_01 only supports sw rx checksum only. Besides,
> the hw rx checksum for RTL_VER_02 is disabled after
> commit b9a321b48af4 ("r8152: Fix broken RX checksums."). Re-enable it.
Excuse me. If I want to re-send this one patch, should I let
RTL_VER_02 use rx hw checksum?
Best Regards,
Hayes
^ permalink raw reply
* Re: [PATCH] net: dsa: mv88e6xxx: Respect SPEED_UNFORCED, don't set force bit
From: Vivien Didelot @ 2016-11-17 3:25 UTC (permalink / raw)
To: Andrew Lunn, David Miller; +Cc: netdev, Andrew Lunn
In-Reply-To: <1479266808-10957-1-git-send-email-andrew@lunn.ch>
Hi Andrew,
Andrew Lunn <andrew@lunn.ch> writes:
> The SPEED_UNFORCED indicates the MAC & PHY should perform
> auto-negotiation to determine a speed which works. If this is called
> for, don't set the force bit. If it is set, the MAC actually does
> 10Gbps, why the internal PHYs don't support.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Fixes: 96a2b40c7bd3 ("net: dsa: mv88e6xxx: add port's MAC speed setter")
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
David, this is for net-next.
Thanks!
Vivien
^ permalink raw reply
* linux-next: build failure after merge of the tip tree
From: Stephen Rothwell @ 2016-11-17 3:22 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
David Miller, Networking
Cc: linux-next, linux-kernel, Christian Borntraeger, Eric Dumazet
Hi all,
After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
net/core/dev.c: In function 'sk_busy_loop':
net/core/dev.c:5065:3: error: implicit declaration of function 'cpu_relax_lowlatency' [-Werror=implicit-function-declaration]
cpu_relax_lowlatency();
^
Caused by commit
5bd0b85ba8bb ("locking/core, arch: Remove cpu_relax_lowlatency()")
interacting with commit
217f69743681 ("net: busy-poll: allow preemption in sk_busy_loop()")
from the net-next tree.
I have applied the following merge fix patch.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 17 Nov 2016 14:13:05 +1100
Subject: [PATCH] net: busy-poll: fix up for cpu_relax_lowlatency() removal
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index d29d538ec5ad..6b9f8eb55b62 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5062,7 +5062,7 @@ bool sk_busy_loop(struct sock *sk, int nonblock)
return rc;
goto restart;
}
- cpu_relax_lowlatency();
+ cpu_relax();
}
if (napi_poll)
busy_poll_stop(napi, have_poll_lock);
--
2.10.2
--
Cheers,
Stephen Rothwell
^ permalink raw reply related
* Re: [PATCHv2 perf/core 2/2] tools lib bpf: Sync with samples/bpf/libbpf
From: Wangnan (F) @ 2016-11-17 3:21 UTC (permalink / raw)
To: Joe Stringer; +Cc: LKML, netdev, ast, daniel, acme
In-Reply-To: <CAOftzPhXk0LKCt8wQKuqeBnDrj6a4p0YL7P80jhK78eFSAz8WQ@mail.gmail.com>
On 2016/11/17 10:46, Joe Stringer wrote:
> On 16 November 2016 at 18:10, Wangnan (F) <wangnan0@huawei.com> wrote:
>> I'm also working on improving bpf.c. Please have a look at:
>>
>> https://lkml.org/lkml/2016/11/14/1078
>>
>> Since bpf.c is simple, I think we can add more functions and fixes
>> gradually, instead of a full copy.
>>
>> See my inline comment below.
> Ah, I missed this, my apologies. It looks like it will provide much of
> what I need, I can reassess this patch with your series in mind.
>
> One comment though for your patch (I don't have the original thread to
> respond to unfortunately): The map_pin and map_get functions in your
> patch series can be used to pin progs too, so maybe there is a better
> name? You'll see that this patch uses bpf_obj_{pin,get}() - although I
> wouldn't want those to be confused with the libbpf.c objects so maybe
> there's a clearer name that could be used.
The full thread can be found:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1272045.html
(lkml.kernel.org is not working for me, sorry)
In that patch set, bpf_map_pin/get is linked into perf hooks, so BPF script
can pin a map to sysfs. I think this feature would be useful, but I don't
have an example to show how to use it. I didn't provide program pinning/get
interface because in perf hook they are not useful. After rethinking your
suggestion now I think it is okay to provide bpf_obj_{pin,get} in bpf.c
and export bpf_map_pin to perf hook. I'll adjust my own patch.
> I also have some patches to rework the samples/bpf/* code to use
> libbpf instead of the sample code that is there, is it worth me
> submitting that? It will need to wait for your patch to go in, plus a
> merge with davem's tree.
>
>> On 2016/11/17 1:43, Joe Stringer wrote:
[SNIP]
>>> /*
>>> @@ -53,24 +60,71 @@ static int sys_bpf(enum bpf_cmd cmd, union bpf_attr
>>> *attr,
>>> return syscall(__NR_bpf, cmd, attr, size);
>>> }
>>> -int bpf_create_map(enum bpf_map_type map_type, int key_size,
>>> - int value_size, int max_entries)
>>> +int bpf_create_map(enum bpf_map_type map_type, int key_size, int
>>> value_size,
>>> + int max_entries, int map_flags)
>>> {
>>> - union bpf_attr attr;
>>> + union bpf_attr attr = {
>>> + .map_type = map_type,
>>> + .key_size = key_size,
>>> + .value_size = value_size,
>>> + .max_entries = max_entries,
>>> + .map_flags = map_flags,
>>> + };
>>> - memset(&attr, '\0', sizeof(attr));
>>> + return sys_bpf(BPF_MAP_CREATE, &attr, sizeof(attr));
>>> +}
>>>
>>
>> I lost map_flags in original bpf.c. Thanks to your patch. map_flags is
>> useful
>> when creating BPF_MAP_TYPE_PERCPU_HASH: BPF_F_NO_PREALLOC is meanful in this
>> case.
> Do you want me to resubmit this piece as a separate patch or will you
> address this?
Please send it.
Thank you.
^ permalink raw reply
* RE: [PATCH net 2/2] r8152: rx descriptor check
From: Hayes Wang @ 2016-11-17 3:05 UTC (permalink / raw)
To: Francois Romieu
Cc: netdev@vger.kernel.org, nic_swsd, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org, mlord@pobox.com
In-Reply-To: <20161115011044.GA13220@electric-eye.fr.zoreil.com>
Francois Romieu [mailto:romieu@fr.zoreil.com]
> Sent: Tuesday, November 15, 2016 9:11 AM
[...]
> If it was possible to get it wrong once, it should be possible to
> get it wrong twice, especially if some part of the hardware design
> is recycled. I don't mean anything else.
I agree with you. However, I have to let it could be reproduced
for confirming it.
Besides, the behavior is different for PCIe and USB device. There
is no action of DMA for USB device. It is done by the USB host
controller. And, the USB host controller wouldn't allow the device
sends a data which is more than the size of the buffer.
Best Regards,
Hayes
^ permalink raw reply
* linux-next: manual merge of the tip tree with the net-next tree
From: Stephen Rothwell @ 2016-11-17 3:04 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
David Miller, Networking
Cc: linux-next, linux-kernel, Nicolas Pitre, Thomas Lendacky
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
drivers/net/ethernet/amd/Kconfig
between commits:
e78332b2285d ("amd-xgbe: Add ECC status support for the device memory")
abf0a1c2b26a ("amd-xgbe: Add support for SFP+ modules")
from the net-next tree and commit:
d1cbfd771ce8 ("ptp_clock: Allow for it to be optional")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/amd/Kconfig
index 7ab6efbe4189,713ea7ad22c3..000000000000
--- a/drivers/net/ethernet/amd/Kconfig
+++ b/drivers/net/ethernet/amd/Kconfig
@@@ -173,13 -173,11 +173,13 @@@ config SUNLANC
config AMD_XGBE
tristate "AMD 10GbE Ethernet driver"
- depends on ((OF_NET && OF_ADDRESS) || ACPI) && HAS_IOMEM && HAS_DMA
- depends on ARM64 || COMPILE_TEST
+ depends on ((OF_NET && OF_ADDRESS) || ACPI || PCI) && HAS_IOMEM && HAS_DMA
+ depends on X86 || ARM64 || COMPILE_TEST
select BITREVERSE
select CRC32
- select PTP_1588_CLOCK
+ select PHYLIB
+ select AMD_XGBE_HAVE_ECC if X86
+ imply PTP_1588_CLOCK
---help---
This driver supports the AMD 10GbE Ethernet device found on an
AMD SoC.
^ permalink raw reply
* Re: [PATCHv2 perf/core 2/2] tools lib bpf: Sync with samples/bpf/libbpf
From: Joe Stringer @ 2016-11-17 2:46 UTC (permalink / raw)
To: Wangnan (F); +Cc: Joe Stringer, LKML, netdev, ast, daniel, acme
In-Reply-To: <582D11B0.80208@huawei.com>
On 16 November 2016 at 18:10, Wangnan (F) <wangnan0@huawei.com> wrote:
> I'm also working on improving bpf.c. Please have a look at:
>
> https://lkml.org/lkml/2016/11/14/1078
>
> Since bpf.c is simple, I think we can add more functions and fixes
> gradually, instead of a full copy.
>
> See my inline comment below.
Ah, I missed this, my apologies. It looks like it will provide much of
what I need, I can reassess this patch with your series in mind.
One comment though for your patch (I don't have the original thread to
respond to unfortunately): The map_pin and map_get functions in your
patch series can be used to pin progs too, so maybe there is a better
name? You'll see that this patch uses bpf_obj_{pin,get}() - although I
wouldn't want those to be confused with the libbpf.c objects so maybe
there's a clearer name that could be used.
I also have some patches to rework the samples/bpf/* code to use
libbpf instead of the sample code that is there, is it worth me
submitting that? It will need to wait for your patch to go in, plus a
merge with davem's tree.
>
> On 2016/11/17 1:43, Joe Stringer wrote:
>>
>> Extend the tools/ version of libbpf to include all of the functionality
>> provided in the samples/bpf version.
>>
>> Signed-off-by: Joe Stringer <joe@ovn.org>
>> ---
>> v2: Don't shift non-bpf changes across.
>> Various type cleanups, removal of extraneous declarations
>> ---
>> tools/lib/bpf/bpf.c | 107 ++++++++++++++++++++------
>> tools/lib/bpf/bpf.h | 202
>> +++++++++++++++++++++++++++++++++++++++++++++++--
>> tools/lib/bpf/libbpf.c | 3 +-
>> 3 files changed, 279 insertions(+), 33 deletions(-)
>>
>> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
>> index 4212ed62235b..5e061851ac00 100644
>> --- a/tools/lib/bpf/bpf.c
>> +++ b/tools/lib/bpf/bpf.c
>> @@ -20,10 +20,17 @@
>> */
>> #include <stdlib.h>
>> -#include <memory.h>
>> +#include <stdio.h>
>> #include <unistd.h>
>> #include <asm/unistd.h>
>> +#include <string.h>
>> +#include <linux/netlink.h>
>> #include <linux/bpf.h>
>> +#include <errno.h>
>> +#include <net/ethernet.h>
>> +#include <net/if.h>
>> +#include <linux/if_packet.h>
>> +#include <arpa/inet.h>
>> #include "bpf.h"
>>
>
>
> Why we need these network related headers?
I started with a copy/paste, assuming that the headers were all in use
but I guess that assumption was wrong.
>> /*
>> @@ -53,24 +60,71 @@ static int sys_bpf(enum bpf_cmd cmd, union bpf_attr
>> *attr,
>> return syscall(__NR_bpf, cmd, attr, size);
>> }
>> -int bpf_create_map(enum bpf_map_type map_type, int key_size,
>> - int value_size, int max_entries)
>> +int bpf_create_map(enum bpf_map_type map_type, int key_size, int
>> value_size,
>> + int max_entries, int map_flags)
>> {
>> - union bpf_attr attr;
>> + union bpf_attr attr = {
>> + .map_type = map_type,
>> + .key_size = key_size,
>> + .value_size = value_size,
>> + .max_entries = max_entries,
>> + .map_flags = map_flags,
>> + };
>> - memset(&attr, '\0', sizeof(attr));
>> + return sys_bpf(BPF_MAP_CREATE, &attr, sizeof(attr));
>> +}
>>
>
>
> I lost map_flags in original bpf.c. Thanks to your patch. map_flags is
> useful
> when creating BPF_MAP_TYPE_PERCPU_HASH: BPF_F_NO_PREALLOC is meanful in this
> case.
Do you want me to resubmit this piece as a separate patch or will you
address this?
> Although it is okay in samples, I still prefer a explicit bzero() or
> memset(),
> because kernel checks if unused field in this union is zero. However I'll
> check
> c standard to see how unused field would be initialized.
OK.
>> diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
>> index e8ba54087497..4dba36995771 100644
>> --- a/tools/lib/bpf/bpf.h
>> +++ b/tools/lib/bpf/bpf.h
>> @@ -23,16 +23,202 @@
>> #include <linux/bpf.h>
>> +struct bpf_insn;
>> +
>> int bpf_create_map(enum bpf_map_type map_type, int key_size, int
>> value_size,
>> - int max_entries);
>> + int max_entries, int map_flags);
>> +int bpf_update_elem(int fd, void *key, void *value, unsigned long long
>> flags);
>> +int bpf_lookup_elem(int fd, void *key, void *value);
>> +int bpf_delete_elem(int fd, void *key);
>> +int bpf_get_next_key(int fd, void *key, void *next_key);
>> +
>> +int bpf_load_program(enum bpf_prog_type prog_type,
>> + const struct bpf_insn *insns, int insn_len,
>> + const char *license, int kern_version,
>> + char *log_buf, size_t log_buf_sz);
>> +
>> +int bpf_obj_pin(int fd, const char *pathname);
>> +int bpf_obj_get(const char *pathname);
>> -/* Recommend log buffer size */
>> #define BPF_LOG_BUF_SIZE 65536
>> -int bpf_load_program(enum bpf_prog_type type, struct bpf_insn *insns,
>> - size_t insns_cnt, char *license,
>> - u32 kern_version, char *log_buf,
>> - size_t log_buf_sz);
>> -int bpf_map_update_elem(int fd, void *key, void *value,
>> - u64 flags);
>> +/* ALU ops on registers, bpf_add|sub|...: dst_reg += src_reg */
>> +
>> +#define BPF_ALU64_REG(OP, DST, SRC) \
>> + ((struct bpf_insn) { \
>> + .code = BPF_ALU64 | BPF_OP(OP) | BPF_X, \
>> + .dst_reg = DST, \
>> + .src_reg = SRC, \
>> + .off = 0, \
>> + .imm = 0 })
>> +
>
>
> Should we define these macros here? They are in include/linux/filter.h
> and duplicated in tools/include/linux/filter.h. Redefining them here
> would cause conflict.
Probably not; including the correct header file would be sufficient.
^ permalink raw reply
* Re: [PATCH] net: ethernet: faraday: To support device tree usage.
From: Greentime Hu @ 2016-11-17 2:37 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Andrew Lunn, netdev, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <7309308.u1IWIyx3Gm@wuerfel>
On Thu, Nov 17, 2016 at 12:12 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Wednesday, November 16, 2016 3:37:15 PM CET Andrew Lunn wrote:
>> On Wed, Nov 16, 2016 at 10:26:52PM +0800, Greentime Hu wrote:
>> > On Wed, Nov 16, 2016 at 9:47 PM, Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org> wrote:
>> > > On Wed, Nov 16, 2016 at 04:43:15PM +0800, Greentime Hu wrote:
>> > >> To support device tree usage for ftmac100.
>> > >>
>> > >> Signed-off-by: Greentime Hu <green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> > >> ---
>> > >> drivers/net/ethernet/faraday/ftmac100.c | 7 +++++++
>> > >> 1 file changed, 7 insertions(+)
>> > >>
>> > >> diff --git a/drivers/net/ethernet/faraday/ftmac100.c b/drivers/net/ethernet/faraday/ftmac100.c
>> > >> index dce5f7b..81dd9e1 100644
>> > >> --- a/drivers/net/ethernet/faraday/ftmac100.c
>> > >> +++ b/drivers/net/ethernet/faraday/ftmac100.c
>> > >> @@ -1172,11 +1172,17 @@ static int __exit ftmac100_remove(struct platform_device *pdev)
>> > >> return 0;
>> > >> }
>> > >>
>> > >> +static const struct of_device_id mac_of_ids[] = {
>> > >> + { .compatible = "andestech,atmac100" },
>> > >> + { }
>> > >
>> > > andestech is not in
>> > > Documentation/devicetree/bindings/vendor-prefixes.txt Please provide a
>> > > separate patch adding it.
>> > OK. I will provide another patch to add andestech.
>> >
>> > > Humm, why andestech? Why not something based around faraday
>> > > technology?
>> > It is because we use the same ftmac100 IP provided from faraday
>> > technology but I am now using it in andestech SoC.
>>
>> Please make sure you get an acked-by: from the device tree
>> maintainers. They might want you to use faraday, since that is the
>> original IP provider. For example, all Synopsys licensed IP uses
>> "snps,XXX", not the SoC vendor with the license.
>
> I think ideally we have both the ID from andes and from faraday here.
>
> Note that we already have "moxa,moxart-mac" as a compatible string
> for this hardware, though it uses a different driver.
>
> We should probably have a single binding document describing
> both compatible strings and any optional properties.
>
> Arnd
I am agree with that.
Andes got this ftmac100 ip from faraday and we refined it.
We rename it to atmac100 to provide to our customer.
These 2 mac100 are using different hardware RTL code but they are
software compatible.
Most of the IPs in Andes SoC are named as atXXX in its dts.
I suggest using this string "andestech,atmac100".
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: marvell: Allow drivers to be built with COMPILE_TEST
From: kbuild test robot @ 2016-11-17 2:30 UTC (permalink / raw)
To: Florian Fainelli
Cc: kbuild-all, netdev, davem, mw, arnd, gregory.clement, Shaohui.Xie,
Florian Fainelli
In-Reply-To: <20161116003541.18415-4-f.fainelli@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]
Hi Florian,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-fsl-Allow-most-drivers-to-be-built-with-COMPILE_TEST/20161116-094841
config: m32r-allmodconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 6.2.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m32r
All errors (new ones prefixed by >>):
ERROR: "bad_dma_ops" [sound/core/snd-pcm.ko] undefined!
ERROR: "dma_common_mmap" [sound/core/snd-pcm.ko] undefined!
>> ERROR: "bad_dma_ops" [drivers/net/ethernet/marvell/mvpp2.ko] undefined!
ERROR: "mvebu_mbus_get_dram_win_info" [drivers/net/ethernet/marvell/mvneta_bm.ko] undefined!
>> ERROR: "bad_dma_ops" [drivers/net/ethernet/marvell/mvneta_bm.ko] undefined!
>> ERROR: "bad_dma_ops" [drivers/net/ethernet/marvell/mvneta.ko] undefined!
>> ERROR: "bad_dma_ops" [drivers/net/ethernet/marvell/mv643xx_eth.ko] undefined!
ERROR: "bad_dma_ops" [drivers/net/ethernet/freescale/gianfar_driver.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 37029 bytes --]
^ permalink raw reply
* [PATCH net-next] af_packet: Use virtio_net_hdr_to_skb().
From: Jarno Rajahalme @ 2016-11-17 2:23 UTC (permalink / raw)
To: netdev; +Cc: jarno
Use the common virtio_net_hdr_to_skb() instead of open coding it.
Other call sites were changed by commit fd2a0437dc, but this one was
missed, maybe because it is split in two parts of the source code.
Also fix other call sites to be more uniform.
Fixes: fd2a0437dc ("virtio_net: introduce virtio_net_hdr_{from,to}_skb")
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
---
drivers/net/macvtap.c | 5 ++---
drivers/net/tun.c | 12 ++++--------
include/linux/virtio_net.h | 2 +-
net/packet/af_packet.c | 44 +-------------------------------------------
4 files changed, 8 insertions(+), 55 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 070e329..5da9861 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -821,9 +821,8 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q,
if (iov_iter_count(iter) < vnet_hdr_len)
return -EINVAL;
- ret = virtio_net_hdr_from_skb(skb, &vnet_hdr,
- macvtap_is_little_endian(q));
- if (ret)
+ if (virtio_net_hdr_from_skb(skb, &vnet_hdr,
+ macvtap_is_little_endian(q)))
BUG();
if (copy_to_iter(&vnet_hdr, sizeof(vnet_hdr), iter) !=
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 9328568..864aae3 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1252,8 +1252,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
return -EFAULT;
}
- err = virtio_net_hdr_to_skb(skb, &gso, tun_is_little_endian(tun));
- if (err) {
+ if (virtio_net_hdr_to_skb(skb, &gso, tun_is_little_endian(tun))) {
this_cpu_inc(tun->pcpu_stats->rx_frame_errors);
kfree_skb(skb);
return -EINVAL;
@@ -1361,15 +1360,12 @@ static ssize_t tun_put_user(struct tun_struct *tun,
}
if (vnet_hdr_sz) {
- struct virtio_net_hdr gso = { 0 }; /* no info leak */
- int ret;
-
+ struct virtio_net_hdr gso;
if (iov_iter_count(iter) < vnet_hdr_sz)
return -EINVAL;
- ret = virtio_net_hdr_from_skb(skb, &gso,
- tun_is_little_endian(tun));
- if (ret) {
+ if (virtio_net_hdr_from_skb(skb, &gso,
+ tun_is_little_endian(tun))) {
struct skb_shared_info *sinfo = skb_shinfo(skb);
pr_err("unexpected GSO type: "
"0x%x, gso_size %d, hdr_len %d\n",
diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
index 1c912f8..74f1e33 100644
--- a/include/linux/virtio_net.h
+++ b/include/linux/virtio_net.h
@@ -98,4 +98,4 @@ static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,
return 0;
}
-#endif /* _LINUX_VIRTIO_BYTEORDER */
+#endif /* _LINUX_VIRTIO_NET_H */
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 11db0d6..09abb88 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1971,8 +1971,6 @@ static unsigned int run_filter(struct sk_buff *skb,
static int __packet_rcv_vnet(const struct sk_buff *skb,
struct virtio_net_hdr *vnet_hdr)
{
- *vnet_hdr = (const struct virtio_net_hdr) { 0 };
-
if (virtio_net_hdr_from_skb(skb, vnet_hdr, vio_le()))
BUG();
@@ -2391,8 +2389,6 @@ static void tpacket_set_protocol(const struct net_device *dev,
static int __packet_snd_vnet_parse(struct virtio_net_hdr *vnet_hdr, size_t len)
{
- unsigned short gso_type = 0;
-
if ((vnet_hdr->flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) &&
(__virtio16_to_cpu(vio_le(), vnet_hdr->csum_start) +
__virtio16_to_cpu(vio_le(), vnet_hdr->csum_offset) + 2 >
@@ -2404,29 +2400,6 @@ static int __packet_snd_vnet_parse(struct virtio_net_hdr *vnet_hdr, size_t len)
if (__virtio16_to_cpu(vio_le(), vnet_hdr->hdr_len) > len)
return -EINVAL;
- if (vnet_hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) {
- switch (vnet_hdr->gso_type & ~VIRTIO_NET_HDR_GSO_ECN) {
- case VIRTIO_NET_HDR_GSO_TCPV4:
- gso_type = SKB_GSO_TCPV4;
- break;
- case VIRTIO_NET_HDR_GSO_TCPV6:
- gso_type = SKB_GSO_TCPV6;
- break;
- case VIRTIO_NET_HDR_GSO_UDP:
- gso_type = SKB_GSO_UDP;
- break;
- default:
- return -EINVAL;
- }
-
- if (vnet_hdr->gso_type & VIRTIO_NET_HDR_GSO_ECN)
- gso_type |= SKB_GSO_TCP_ECN;
-
- if (vnet_hdr->gso_size == 0)
- return -EINVAL;
- }
-
- vnet_hdr->gso_type = gso_type; /* changes type, temporary storage */
return 0;
}
@@ -2449,22 +2422,7 @@ static int packet_snd_vnet_parse(struct msghdr *msg, size_t *len,
static int packet_snd_vnet_gso(struct sk_buff *skb,
struct virtio_net_hdr *vnet_hdr)
{
- if (vnet_hdr->flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) {
- u16 s = __virtio16_to_cpu(vio_le(), vnet_hdr->csum_start);
- u16 o = __virtio16_to_cpu(vio_le(), vnet_hdr->csum_offset);
-
- if (!skb_partial_csum_set(skb, s, o))
- return -EINVAL;
- }
-
- skb_shinfo(skb)->gso_size =
- __virtio16_to_cpu(vio_le(), vnet_hdr->gso_size);
- skb_shinfo(skb)->gso_type = vnet_hdr->gso_type;
-
- /* Header must be checked, and gso_segs computed. */
- skb_shinfo(skb)->gso_type |= SKB_GSO_DODGY;
- skb_shinfo(skb)->gso_segs = 0;
- return 0;
+ return virtio_net_hdr_to_skb(skb, vnet_hdr, vio_le());
}
static int tpacket_fill_skb(struct packet_sock *po, struct sk_buff *skb,
--
2.1.4
^ permalink raw reply related
* [PATCH net-next 1/4] bnxt_en: Update firmware interface spec to 1.5.4.
From: Michael Chan @ 2016-11-17 2:13 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1479348790-6218-1-git-send-email-michael.chan@broadcom.com>
Use the new FORCE_LINK_DWN bit to shutdown link during close.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 8 ++-
drivers/net/ethernet/broadcom/bnxt/bnxt_hsi.h | 91 +++++++++++++++++++++++++--
2 files changed, 94 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 27a2dd9..1332577 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -5346,7 +5346,7 @@ static int bnxt_hwrm_shutdown_link(struct bnxt *bp)
return 0;
bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_PORT_PHY_CFG, -1, -1);
- req.flags = cpu_to_le32(PORT_PHY_CFG_REQ_FLAGS_FORCE_LINK_DOWN);
+ req.flags = cpu_to_le32(PORT_PHY_CFG_REQ_FLAGS_FORCE_LINK_DWN);
return hwrm_send_message(bp, &req, sizeof(req), HWRM_CMD_TIMEOUT);
}
@@ -5409,6 +5409,12 @@ static int bnxt_update_phy_setting(struct bnxt *bp)
update_link = true;
}
+ /* The last close may have shutdown the link, so need to call
+ * PHY_CFG to bring it back up.
+ */
+ if (!netif_carrier_ok(bp->dev))
+ update_link = true;
+
if (!bnxt_eee_config_ok(bp))
update_eee = true;
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_hsi.h b/drivers/net/ethernet/broadcom/bnxt/bnxt_hsi.h
index 04a96cc..0456d5b 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_hsi.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_hsi.h
@@ -215,6 +215,9 @@ struct hwrm_async_event_cmpl_dcb_config_change {
__le16 event_id;
#define HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_ID_DCB_CONFIG_CHANGE 0x3UL
__le32 event_data2;
+ #define HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA2_ETS 0x1UL
+ #define HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA2_PFC 0x2UL
+ #define HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA2_APP 0x4UL
u8 opaque_v;
#define HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_V 0x1UL
#define HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_OPAQUE_MASK 0xfeUL
@@ -224,6 +227,14 @@ struct hwrm_async_event_cmpl_dcb_config_change {
__le32 event_data1;
#define HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA1_PORT_ID_MASK 0xffffUL
#define HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA1_PORT_ID_SFT 0
+ #define HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA1_RECOMMEND_ROCE_PRIORITY_MASK 0xff0000UL
+ #define HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA1_RECOMMEND_ROCE_PRIORITY_SFT 16
+ #define HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA1_RECOMMEND_ROCE_PRIORITY_NONE (0xffUL << 16)
+ #define HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA1_RECOMMEND_ROCE_PRIORITY_LAST HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA1_RECOMMEND_ROCE_PRIORITY_NONE
+ #define HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA1_RECOMMEND_L2_PRIORITY_MASK 0xff000000UL
+ #define HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA1_RECOMMEND_L2_PRIORITY_SFT 24
+ #define HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA1_RECOMMEND_L2_PRIORITY_NONE (0xffUL << 24)
+ #define HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA1_RECOMMEND_L2_PRIORITY_LAST HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA1_RECOMMEND_L2_PRIORITY_NONE
};
/* HWRM Asynchronous Event Completion Record for port connection not allowed (16 bytes) */
@@ -485,12 +496,12 @@ struct hwrm_async_event_cmpl_hwrm_error {
#define HWRM_ASYNC_EVENT_CMPL_HWRM_ERROR_EVENT_DATA1_TIMESTAMP 0x1UL
};
-/* HW Resource Manager Specification 1.5.1 */
+/* HW Resource Manager Specification 1.5.4 */
#define HWRM_VERSION_MAJOR 1
#define HWRM_VERSION_MINOR 5
-#define HWRM_VERSION_UPDATE 1
+#define HWRM_VERSION_UPDATE 4
-#define HWRM_VERSION_STR "1.5.1"
+#define HWRM_VERSION_STR "1.5.4"
/*
* Following is the signature for HWRM message field that indicates not
* applicable (All F's). Need to cast it the size of the field if needed.
@@ -612,6 +623,9 @@ struct cmd_nums {
#define HWRM_FW_QSTATUS (0xc1UL)
#define HWRM_FW_SET_TIME (0xc8UL)
#define HWRM_FW_GET_TIME (0xc9UL)
+ #define HWRM_FW_SET_STRUCTURED_DATA (0xcaUL)
+ #define HWRM_FW_GET_STRUCTURED_DATA (0xcbUL)
+ #define HWRM_FW_IPC_MAILBOX (0xccUL)
#define HWRM_EXEC_FWD_RESP (0xd0UL)
#define HWRM_REJECT_FWD_RESP (0xd1UL)
#define HWRM_FWD_RESP (0xd2UL)
@@ -626,6 +640,8 @@ struct cmd_nums {
#define HWRM_DBG_WRITE_DIRECT (0xff12UL)
#define HWRM_DBG_WRITE_INDIRECT (0xff13UL)
#define HWRM_DBG_DUMP (0xff14UL)
+ #define HWRM_NVM_GET_VARIABLE (0xfff1UL)
+ #define HWRM_NVM_SET_VARIABLE (0xfff2UL)
#define HWRM_NVM_INSTALL_UPDATE (0xfff3UL)
#define HWRM_NVM_MODIFY (0xfff4UL)
#define HWRM_NVM_VERIFY_UPDATE (0xfff5UL)
@@ -1399,6 +1415,7 @@ struct hwrm_func_drv_rgtr_input {
#define FUNC_DRV_RGTR_REQ_OS_TYPE_ESXI 0x68UL
#define FUNC_DRV_RGTR_REQ_OS_TYPE_WIN864 0x73UL
#define FUNC_DRV_RGTR_REQ_OS_TYPE_WIN2012R2 0x74UL
+ #define FUNC_DRV_RGTR_REQ_OS_TYPE_UEFI 0x8000UL
u8 ver_maj;
u8 ver_min;
u8 ver_upd;
@@ -1549,7 +1566,7 @@ struct hwrm_port_phy_cfg_input {
__le64 resp_addr;
__le32 flags;
#define PORT_PHY_CFG_REQ_FLAGS_RESET_PHY 0x1UL
- #define PORT_PHY_CFG_REQ_FLAGS_FORCE_LINK_DOWN 0x2UL
+ #define PORT_PHY_CFG_REQ_FLAGS_DEPRECATED 0x2UL
#define PORT_PHY_CFG_REQ_FLAGS_FORCE 0x4UL
#define PORT_PHY_CFG_REQ_FLAGS_RESTART_AUTONEG 0x8UL
#define PORT_PHY_CFG_REQ_FLAGS_EEE_ENABLE 0x10UL
@@ -1562,6 +1579,7 @@ struct hwrm_port_phy_cfg_input {
#define PORT_PHY_CFG_REQ_FLAGS_FEC_CLAUSE74_DISABLE 0x800UL
#define PORT_PHY_CFG_REQ_FLAGS_FEC_CLAUSE91_ENABLE 0x1000UL
#define PORT_PHY_CFG_REQ_FLAGS_FEC_CLAUSE91_DISABLE 0x2000UL
+ #define PORT_PHY_CFG_REQ_FLAGS_FORCE_LINK_DWN 0x4000UL
__le32 enables;
#define PORT_PHY_CFG_REQ_ENABLES_AUTO_MODE 0x1UL
#define PORT_PHY_CFG_REQ_ENABLES_AUTO_DUPLEX 0x2UL
@@ -4023,6 +4041,71 @@ struct hwrm_fw_set_time_output {
u8 valid;
};
+/* hwrm_fw_set_structured_data */
+/* Input (32 bytes) */
+struct hwrm_fw_set_structured_data_input {
+ __le16 req_type;
+ __le16 cmpl_ring;
+ __le16 seq_id;
+ __le16 target_id;
+ __le64 resp_addr;
+ __le64 src_data_addr;
+ __le16 data_len;
+ u8 hdr_cnt;
+ u8 unused_0[5];
+};
+
+/* Output (16 bytes) */
+struct hwrm_fw_set_structured_data_output {
+ __le16 error_code;
+ __le16 req_type;
+ __le16 seq_id;
+ __le16 resp_len;
+ __le32 unused_0;
+ u8 unused_1;
+ u8 unused_2;
+ u8 unused_3;
+ u8 valid;
+};
+
+/* hwrm_fw_get_structured_data */
+/* Input (32 bytes) */
+struct hwrm_fw_get_structured_data_input {
+ __le16 req_type;
+ __le16 cmpl_ring;
+ __le16 seq_id;
+ __le16 target_id;
+ __le64 resp_addr;
+ __le64 dest_data_addr;
+ __le16 data_len;
+ __le16 structure_id;
+ __le16 subtype;
+ #define FW_GET_STRUCTURED_DATA_REQ_SUBTYPE_ALL 0xffffUL
+ #define FW_GET_STRUCTURED_DATA_REQ_SUBTYPE_NEAR_BRIDGE_ADMIN 0x100UL
+ #define FW_GET_STRUCTURED_DATA_REQ_SUBTYPE_NEAR_BRIDGE_PEER 0x101UL
+ #define FW_GET_STRUCTURED_DATA_REQ_SUBTYPE_NEAR_BRIDGE_OPERATIONAL 0x102UL
+ #define FW_GET_STRUCTURED_DATA_REQ_SUBTYPE_NON_TPMR_ADMIN 0x200UL
+ #define FW_GET_STRUCTURED_DATA_REQ_SUBTYPE_NON_TPMR_PEER 0x201UL
+ #define FW_GET_STRUCTURED_DATA_REQ_SUBTYPE_NON_TPMR_OPERATIONAL 0x202UL
+ u8 count;
+ u8 unused_0;
+};
+
+/* Output (16 bytes) */
+struct hwrm_fw_get_structured_data_output {
+ __le16 error_code;
+ __le16 req_type;
+ __le16 seq_id;
+ __le16 resp_len;
+ u8 hdr_cnt;
+ u8 unused_0;
+ __le16 unused_1;
+ u8 unused_2;
+ u8 unused_3;
+ u8 unused_4;
+ u8 valid;
+};
+
/* hwrm_exec_fwd_resp */
/* Input (128 bytes) */
struct hwrm_exec_fwd_resp_input {
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 0/4] bnxt_en: Updates.
From: Michael Chan @ 2016-11-17 2:13 UTC (permalink / raw)
To: davem; +Cc: netdev
New firmware spec. update, autoneg update, and UDP RSS support.
Michael Chan (4):
bnxt_en: Update firmware interface spec to 1.5.4.
bnxt_en: Enhance autoneg support.
bnxt_en: Add UDP RSS support for 57X1X chips.
bnxt_en: Add ethtool -n|-N rx-flow-hash support.
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 52 +++++--
drivers/net/ethernet/broadcom/bnxt/bnxt.h | 4 +-
drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 167 +++++++++++++++++++++-
drivers/net/ethernet/broadcom/bnxt/bnxt_hsi.h | 91 +++++++++++-
4 files changed, 298 insertions(+), 16 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH net-next 3/4] bnxt_en: Add UDP RSS support for 57X1X chips.
From: Michael Chan @ 2016-11-17 2:13 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1479348790-6218-1-git-send-email-michael.chan@broadcom.com>
The newer chips have proper support for 4-tuple UDP RSS.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 21 ++++++++++++++-------
drivers/net/ethernet/broadcom/bnxt/bnxt.h | 3 ++-
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 4db50e8..7401c90 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -3425,13 +3425,7 @@ static int bnxt_hwrm_vnic_set_rss(struct bnxt *bp, u16 vnic_id, bool set_rss)
bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_VNIC_RSS_CFG, -1, -1);
if (set_rss) {
- vnic->hash_type = VNIC_RSS_CFG_REQ_HASH_TYPE_IPV4 |
- VNIC_RSS_CFG_REQ_HASH_TYPE_TCP_IPV4 |
- VNIC_RSS_CFG_REQ_HASH_TYPE_IPV6 |
- VNIC_RSS_CFG_REQ_HASH_TYPE_TCP_IPV6;
-
- req.hash_type = cpu_to_le32(vnic->hash_type);
-
+ req.hash_type = cpu_to_le32(bp->rss_hash_cfg);
if (vnic->flags & BNXT_VNIC_RSS_FLAG) {
if (BNXT_CHIP_TYPE_NITRO_A0(bp))
max_rings = bp->rx_nr_rings - 1;
@@ -6940,6 +6934,19 @@ static int bnxt_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
#endif
bnxt_set_dflt_rings(bp);
+ /* Default RSS hash cfg. */
+ bp->rss_hash_cfg = VNIC_RSS_CFG_REQ_HASH_TYPE_IPV4 |
+ VNIC_RSS_CFG_REQ_HASH_TYPE_TCP_IPV4 |
+ VNIC_RSS_CFG_REQ_HASH_TYPE_IPV6 |
+ VNIC_RSS_CFG_REQ_HASH_TYPE_TCP_IPV6;
+ if (!BNXT_CHIP_NUM_57X0X(bp->chip_num) &&
+ !BNXT_CHIP_TYPE_NITRO_A0(bp) &&
+ bp->hwrm_spec_code >= 0x10501) {
+ bp->flags |= BNXT_FLAG_UDP_RSS_CAP;
+ bp->rss_hash_cfg |= VNIC_RSS_CFG_REQ_HASH_TYPE_UDP_IPV4 |
+ VNIC_RSS_CFG_REQ_HASH_TYPE_UDP_IPV6;
+ }
+
if (BNXT_PF(bp) && !BNXT_CHIP_TYPE_NITRO_A0(bp)) {
dev->hw_features |= NETIF_F_NTUPLE;
if (bnxt_rfs_capable(bp)) {
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.h b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
index 666bc06..47be789 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
@@ -700,7 +700,6 @@ struct bnxt_vnic_info {
u8 *uc_list;
u16 *fw_grp_ids;
- u16 hash_type;
dma_addr_t rss_table_dma_addr;
__le16 *rss_table;
dma_addr_t rss_hash_key_dma_addr;
@@ -952,6 +951,7 @@ struct bnxt {
#define BNXT_FLAG_RFS 0x100
#define BNXT_FLAG_SHARED_RINGS 0x200
#define BNXT_FLAG_PORT_STATS 0x400
+ #define BNXT_FLAG_UDP_RSS_CAP 0x800
#define BNXT_FLAG_EEE_CAP 0x1000
#define BNXT_FLAG_CHIP_NITRO_A0 0x1000000
@@ -1007,6 +1007,7 @@ struct bnxt {
struct bnxt_ring_grp_info *grp_info;
struct bnxt_vnic_info *vnic_info;
int nr_vnics;
+ u32 rss_hash_cfg;
u8 max_tc;
struct bnxt_queue_info q_info[BNXT_MAX_QUEUE];
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 4/4] bnxt_en: Add ethtool -n|-N rx-flow-hash support.
From: Michael Chan @ 2016-11-17 2:13 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1479348790-6218-1-git-send-email-michael.chan@broadcom.com>
To display and modify the RSS hash.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 167 +++++++++++++++++++++-
1 file changed, 164 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
index a7e04ff..fa6125e 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
@@ -542,6 +542,146 @@ static int bnxt_grxclsrule(struct bnxt *bp, struct ethtool_rxnfc *cmd)
return rc;
}
+#endif
+
+static u64 get_ethtool_ipv4_rss(struct bnxt *bp)
+{
+ if (bp->rss_hash_cfg & VNIC_RSS_CFG_REQ_HASH_TYPE_IPV4)
+ return RXH_IP_SRC | RXH_IP_DST;
+ return 0;
+}
+
+static u64 get_ethtool_ipv6_rss(struct bnxt *bp)
+{
+ if (bp->rss_hash_cfg & VNIC_RSS_CFG_REQ_HASH_TYPE_IPV6)
+ return RXH_IP_SRC | RXH_IP_DST;
+ return 0;
+}
+
+static int bnxt_grxfh(struct bnxt *bp, struct ethtool_rxnfc *cmd)
+{
+ cmd->data = 0;
+ switch (cmd->flow_type) {
+ case TCP_V4_FLOW:
+ if (bp->rss_hash_cfg & VNIC_RSS_CFG_REQ_HASH_TYPE_TCP_IPV4)
+ cmd->data |= RXH_IP_SRC | RXH_IP_DST |
+ RXH_L4_B_0_1 | RXH_L4_B_2_3;
+ cmd->data |= get_ethtool_ipv4_rss(bp);
+ break;
+ case UDP_V4_FLOW:
+ if (bp->rss_hash_cfg & VNIC_RSS_CFG_REQ_HASH_TYPE_UDP_IPV4)
+ cmd->data |= RXH_IP_SRC | RXH_IP_DST |
+ RXH_L4_B_0_1 | RXH_L4_B_2_3;
+ /* fall through */
+ case SCTP_V4_FLOW:
+ case AH_ESP_V4_FLOW:
+ case AH_V4_FLOW:
+ case ESP_V4_FLOW:
+ case IPV4_FLOW:
+ cmd->data |= get_ethtool_ipv4_rss(bp);
+ break;
+
+ case TCP_V6_FLOW:
+ if (bp->rss_hash_cfg & VNIC_RSS_CFG_REQ_HASH_TYPE_TCP_IPV6)
+ cmd->data |= RXH_IP_SRC | RXH_IP_DST |
+ RXH_L4_B_0_1 | RXH_L4_B_2_3;
+ cmd->data |= get_ethtool_ipv6_rss(bp);
+ break;
+ case UDP_V6_FLOW:
+ if (bp->rss_hash_cfg & VNIC_RSS_CFG_REQ_HASH_TYPE_UDP_IPV6)
+ cmd->data |= RXH_IP_SRC | RXH_IP_DST |
+ RXH_L4_B_0_1 | RXH_L4_B_2_3;
+ /* fall through */
+ case SCTP_V6_FLOW:
+ case AH_ESP_V6_FLOW:
+ case AH_V6_FLOW:
+ case ESP_V6_FLOW:
+ case IPV6_FLOW:
+ cmd->data |= get_ethtool_ipv6_rss(bp);
+ break;
+ }
+ return 0;
+}
+
+#define RXH_4TUPLE (RXH_IP_SRC | RXH_IP_DST | RXH_L4_B_0_1 | RXH_L4_B_2_3)
+#define RXH_2TUPLE (RXH_IP_SRC | RXH_IP_DST)
+
+static int bnxt_srxfh(struct bnxt *bp, struct ethtool_rxnfc *cmd)
+{
+ u32 rss_hash_cfg = bp->rss_hash_cfg;
+ int tuple, rc = 0;
+
+ if (cmd->data == RXH_4TUPLE)
+ tuple = 4;
+ else if (cmd->data == RXH_2TUPLE)
+ tuple = 2;
+ else if (!cmd->data)
+ tuple = 0;
+ else
+ return -EINVAL;
+
+ if (cmd->flow_type == TCP_V4_FLOW) {
+ rss_hash_cfg &= ~VNIC_RSS_CFG_REQ_HASH_TYPE_TCP_IPV4;
+ if (tuple == 4)
+ rss_hash_cfg |= VNIC_RSS_CFG_REQ_HASH_TYPE_TCP_IPV4;
+ } else if (cmd->flow_type == UDP_V4_FLOW) {
+ if (tuple == 4 && !(bp->flags & BNXT_FLAG_UDP_RSS_CAP))
+ return -EINVAL;
+ rss_hash_cfg &= ~VNIC_RSS_CFG_REQ_HASH_TYPE_UDP_IPV4;
+ if (tuple == 4)
+ rss_hash_cfg |= VNIC_RSS_CFG_REQ_HASH_TYPE_UDP_IPV4;
+ } else if (cmd->flow_type == TCP_V6_FLOW) {
+ rss_hash_cfg &= ~VNIC_RSS_CFG_REQ_HASH_TYPE_TCP_IPV6;
+ if (tuple == 4)
+ rss_hash_cfg |= VNIC_RSS_CFG_REQ_HASH_TYPE_TCP_IPV6;
+ } else if (cmd->flow_type == UDP_V6_FLOW) {
+ if (tuple == 4 && !(bp->flags & BNXT_FLAG_UDP_RSS_CAP))
+ return -EINVAL;
+ rss_hash_cfg &= ~VNIC_RSS_CFG_REQ_HASH_TYPE_UDP_IPV6;
+ if (tuple == 4)
+ rss_hash_cfg |= VNIC_RSS_CFG_REQ_HASH_TYPE_UDP_IPV6;
+ } else if (tuple == 4) {
+ return -EINVAL;
+ }
+
+ switch (cmd->flow_type) {
+ case TCP_V4_FLOW:
+ case UDP_V4_FLOW:
+ case SCTP_V4_FLOW:
+ case AH_ESP_V4_FLOW:
+ case AH_V4_FLOW:
+ case ESP_V4_FLOW:
+ case IPV4_FLOW:
+ if (tuple == 2)
+ rss_hash_cfg |= VNIC_RSS_CFG_REQ_HASH_TYPE_IPV4;
+ else if (!tuple)
+ rss_hash_cfg &= ~VNIC_RSS_CFG_REQ_HASH_TYPE_IPV4;
+ break;
+
+ case TCP_V6_FLOW:
+ case UDP_V6_FLOW:
+ case SCTP_V6_FLOW:
+ case AH_ESP_V6_FLOW:
+ case AH_V6_FLOW:
+ case ESP_V6_FLOW:
+ case IPV6_FLOW:
+ if (tuple == 2)
+ rss_hash_cfg |= VNIC_RSS_CFG_REQ_HASH_TYPE_IPV6;
+ else if (!tuple)
+ rss_hash_cfg &= ~VNIC_RSS_CFG_REQ_HASH_TYPE_IPV6;
+ break;
+ }
+
+ if (bp->rss_hash_cfg == rss_hash_cfg)
+ return 0;
+
+ bp->rss_hash_cfg = rss_hash_cfg;
+ if (netif_running(bp->dev)) {
+ bnxt_close_nic(bp, false, false);
+ rc = bnxt_open_nic(bp, false, false);
+ }
+ return rc;
+}
static int bnxt_get_rxnfc(struct net_device *dev, struct ethtool_rxnfc *cmd,
u32 *rule_locs)
@@ -550,6 +690,7 @@ static int bnxt_get_rxnfc(struct net_device *dev, struct ethtool_rxnfc *cmd,
int rc = 0;
switch (cmd->cmd) {
+#ifdef CONFIG_RFS_ACCEL
case ETHTOOL_GRXRINGS:
cmd->data = bp->rx_nr_rings;
break;
@@ -566,6 +707,11 @@ static int bnxt_get_rxnfc(struct net_device *dev, struct ethtool_rxnfc *cmd,
case ETHTOOL_GRXCLSRULE:
rc = bnxt_grxclsrule(bp, cmd);
break;
+#endif
+
+ case ETHTOOL_GRXFH:
+ rc = bnxt_grxfh(bp, cmd);
+ break;
default:
rc = -EOPNOTSUPP;
@@ -574,7 +720,23 @@ static int bnxt_get_rxnfc(struct net_device *dev, struct ethtool_rxnfc *cmd,
return rc;
}
-#endif
+
+static int bnxt_set_rxnfc(struct net_device *dev, struct ethtool_rxnfc *cmd)
+{
+ struct bnxt *bp = netdev_priv(dev);
+ int rc;
+
+ switch (cmd->cmd) {
+ case ETHTOOL_SRXFH:
+ rc = bnxt_srxfh(bp, cmd);
+ break;
+
+ default:
+ rc = -EOPNOTSUPP;
+ break;
+ }
+ return rc;
+}
static u32 bnxt_get_rxfh_indir_size(struct net_device *dev)
{
@@ -1885,9 +2047,8 @@ static int bnxt_nway_reset(struct net_device *dev)
.get_ringparam = bnxt_get_ringparam,
.get_channels = bnxt_get_channels,
.set_channels = bnxt_set_channels,
-#ifdef CONFIG_RFS_ACCEL
.get_rxnfc = bnxt_get_rxnfc,
-#endif
+ .set_rxnfc = bnxt_set_rxnfc,
.get_rxfh_indir_size = bnxt_get_rxfh_indir_size,
.get_rxfh_key_size = bnxt_get_rxfh_key_size,
.get_rxfh = bnxt_get_rxfh,
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 2/4] bnxt_en: Enhance autoneg support.
From: Michael Chan @ 2016-11-17 2:13 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1479348790-6218-1-git-send-email-michael.chan@broadcom.com>
On some dual port NICs, the speed setting on one port can affect the
available speed on the other port. Add logic to detect these changes
and adjust the advertised speed settings when necessary.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 23 +++++++++++++++++++++++
drivers/net/ethernet/broadcom/bnxt/bnxt.h | 1 +
2 files changed, 24 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 1332577..4db50e8 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -1499,6 +1499,7 @@ static int bnxt_async_event_process(struct bnxt *bp,
netdev_warn(bp->dev, "Link speed %d no longer supported\n",
speed);
}
+ set_bit(BNXT_LINK_SPEED_CHNG_SP_EVENT, &bp->sp_event);
/* fall thru */
}
case HWRM_ASYNC_EVENT_CMPL_EVENT_ID_LINK_STATUS_CHANGE:
@@ -5095,6 +5096,7 @@ static int bnxt_update_link(struct bnxt *bp, bool chng_link_state)
struct hwrm_port_phy_qcfg_input req = {0};
struct hwrm_port_phy_qcfg_output *resp = bp->hwrm_cmd_resp_addr;
u8 link_up = link_info->link_up;
+ u16 diff;
bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_PORT_PHY_QCFG, -1, -1);
@@ -5182,6 +5184,23 @@ static int bnxt_update_link(struct bnxt *bp, bool chng_link_state)
link_info->link_up = 0;
}
mutex_unlock(&bp->hwrm_cmd_lock);
+
+ diff = link_info->support_auto_speeds ^ link_info->advertising;
+ if ((link_info->support_auto_speeds | diff) !=
+ link_info->support_auto_speeds) {
+ /* An advertised speed is no longer supported, so we need to
+ * update the advertisement settings. See bnxt_reset() for
+ * comments about the rtnl_lock() sequence below.
+ */
+ clear_bit(BNXT_STATE_IN_SP_TASK, &bp->state);
+ rtnl_lock();
+ link_info->advertising = link_info->support_auto_speeds;
+ if (test_bit(BNXT_STATE_OPEN, &bp->state) &&
+ (link_info->autoneg & BNXT_AUTONEG_SPEED))
+ bnxt_hwrm_set_link_setting(bp, true, false);
+ set_bit(BNXT_STATE_IN_SP_TASK, &bp->state);
+ rtnl_unlock();
+ }
return 0;
}
@@ -6108,6 +6127,10 @@ static void bnxt_sp_task(struct work_struct *work)
if (test_and_clear_bit(BNXT_RX_NTP_FLTR_SP_EVENT, &bp->sp_event))
bnxt_cfg_ntp_filters(bp);
if (test_and_clear_bit(BNXT_LINK_CHNG_SP_EVENT, &bp->sp_event)) {
+ if (test_and_clear_bit(BNXT_LINK_SPEED_CHNG_SP_EVENT,
+ &bp->sp_event))
+ bnxt_hwrm_phy_qcaps(bp);
+
rc = bnxt_update_link(bp, true);
if (rc)
netdev_err(bp->dev, "SP task can't update link (rc: %x)\n",
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.h b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
index 51b164a..666bc06 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
@@ -1089,6 +1089,7 @@ struct bnxt {
#define BNXT_RESET_TASK_SILENT_SP_EVENT 11
#define BNXT_GENEVE_ADD_PORT_SP_EVENT 12
#define BNXT_GENEVE_DEL_PORT_SP_EVENT 13
+#define BNXT_LINK_SPEED_CHNG_SP_EVENT 14
struct bnxt_pf_info pf;
#ifdef CONFIG_BNXT_SRIOV
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCHv2 perf/core 2/2] tools lib bpf: Sync with samples/bpf/libbpf
From: Wangnan (F) @ 2016-11-17 2:10 UTC (permalink / raw)
To: Joe Stringer, linux-kernel; +Cc: netdev, ast, daniel, acme
In-Reply-To: <20161116174324.29675-3-joe@ovn.org>
I'm also working on improving bpf.c. Please have a look at:
https://lkml.org/lkml/2016/11/14/1078
Since bpf.c is simple, I think we can add more functions and fixes
gradually, instead of a full copy.
See my inline comment below.
On 2016/11/17 1:43, Joe Stringer wrote:
> Extend the tools/ version of libbpf to include all of the functionality
> provided in the samples/bpf version.
>
> Signed-off-by: Joe Stringer <joe@ovn.org>
> ---
> v2: Don't shift non-bpf changes across.
> Various type cleanups, removal of extraneous declarations
> ---
> tools/lib/bpf/bpf.c | 107 ++++++++++++++++++++------
> tools/lib/bpf/bpf.h | 202 +++++++++++++++++++++++++++++++++++++++++++++++--
> tools/lib/bpf/libbpf.c | 3 +-
> 3 files changed, 279 insertions(+), 33 deletions(-)
>
> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> index 4212ed62235b..5e061851ac00 100644
> --- a/tools/lib/bpf/bpf.c
> +++ b/tools/lib/bpf/bpf.c
> @@ -20,10 +20,17 @@
> */
>
> #include <stdlib.h>
> -#include <memory.h>
> +#include <stdio.h>
> #include <unistd.h>
> #include <asm/unistd.h>
> +#include <string.h>
> +#include <linux/netlink.h>
> #include <linux/bpf.h>
> +#include <errno.h>
> +#include <net/ethernet.h>
> +#include <net/if.h>
> +#include <linux/if_packet.h>
> +#include <arpa/inet.h>
> #include "bpf.h"
>
Why we need these network related headers?
> /*
> @@ -53,24 +60,71 @@ static int sys_bpf(enum bpf_cmd cmd, union bpf_attr *attr,
> return syscall(__NR_bpf, cmd, attr, size);
> }
>
> -int bpf_create_map(enum bpf_map_type map_type, int key_size,
> - int value_size, int max_entries)
> +int bpf_create_map(enum bpf_map_type map_type, int key_size, int value_size,
> + int max_entries, int map_flags)
> {
> - union bpf_attr attr;
> + union bpf_attr attr = {
> + .map_type = map_type,
> + .key_size = key_size,
> + .value_size = value_size,
> + .max_entries = max_entries,
> + .map_flags = map_flags,
> + };
>
> - memset(&attr, '\0', sizeof(attr));
> + return sys_bpf(BPF_MAP_CREATE, &attr, sizeof(attr));
> +}
>
I lost map_flags in original bpf.c. Thanks to your patch. map_flags is
useful
when creating BPF_MAP_TYPE_PERCPU_HASH: BPF_F_NO_PREALLOC is meanful in this
case.
Although it is okay in samples, I still prefer a explicit bzero() or
memset(),
because kernel checks if unused field in this union is zero. However
I'll check
c standard to see how unused field would be initialized.
<SNIP>
> diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
> index e8ba54087497..4dba36995771 100644
> --- a/tools/lib/bpf/bpf.h
> +++ b/tools/lib/bpf/bpf.h
> @@ -23,16 +23,202 @@
>
> #include <linux/bpf.h>
>
> +struct bpf_insn;
> +
> int bpf_create_map(enum bpf_map_type map_type, int key_size, int value_size,
> - int max_entries);
> + int max_entries, int map_flags);
> +int bpf_update_elem(int fd, void *key, void *value, unsigned long long flags);
> +int bpf_lookup_elem(int fd, void *key, void *value);
> +int bpf_delete_elem(int fd, void *key);
> +int bpf_get_next_key(int fd, void *key, void *next_key);
> +
> +int bpf_load_program(enum bpf_prog_type prog_type,
> + const struct bpf_insn *insns, int insn_len,
> + const char *license, int kern_version,
> + char *log_buf, size_t log_buf_sz);
> +
> +int bpf_obj_pin(int fd, const char *pathname);
> +int bpf_obj_get(const char *pathname);
>
> -/* Recommend log buffer size */
> #define BPF_LOG_BUF_SIZE 65536
> -int bpf_load_program(enum bpf_prog_type type, struct bpf_insn *insns,
> - size_t insns_cnt, char *license,
> - u32 kern_version, char *log_buf,
> - size_t log_buf_sz);
>
> -int bpf_map_update_elem(int fd, void *key, void *value,
> - u64 flags);
> +/* ALU ops on registers, bpf_add|sub|...: dst_reg += src_reg */
> +
> +#define BPF_ALU64_REG(OP, DST, SRC) \
> + ((struct bpf_insn) { \
> + .code = BPF_ALU64 | BPF_OP(OP) | BPF_X, \
> + .dst_reg = DST, \
> + .src_reg = SRC, \
> + .off = 0, \
> + .imm = 0 })
> +
Should we define these macros here? They are in include/linux/filter.h
and duplicated in tools/include/linux/filter.h. Redefining them here
would cause conflict.
Thank you.
^ permalink raw reply
* [net-next] af_packet: Use virtio_net_hdr_to_skb().
From: Jarno Rajahalme @ 2016-11-17 2:06 UTC (permalink / raw)
To: netdev; +Cc: jarno
Use the common virtio_net_hdr_to_skb() instead of open coding it.
Other call sites were changed by commit fd2a0437dc, but this one was
missed, maybe because it is split in two parts of the source code.
Also fix other call sites to be more uniform.
Fixes: fd2a0437dc ("virtio_net: introduce virtio_net_hdr_{from,to}_skb")
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
---
drivers/net/macvtap.c | 5 ++---
drivers/net/tun.c | 12 ++++--------
include/linux/virtio_net.h | 2 +-
net/packet/af_packet.c | 44 +-------------------------------------------
4 files changed, 8 insertions(+), 55 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 070e329..5da9861 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -821,9 +821,8 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q,
if (iov_iter_count(iter) < vnet_hdr_len)
return -EINVAL;
- ret = virtio_net_hdr_from_skb(skb, &vnet_hdr,
- macvtap_is_little_endian(q));
- if (ret)
+ if (virtio_net_hdr_from_skb(skb, &vnet_hdr,
+ macvtap_is_little_endian(q)))
BUG();
if (copy_to_iter(&vnet_hdr, sizeof(vnet_hdr), iter) !=
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 9328568..864aae3 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1252,8 +1252,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
return -EFAULT;
}
- err = virtio_net_hdr_to_skb(skb, &gso, tun_is_little_endian(tun));
- if (err) {
+ if (virtio_net_hdr_to_skb(skb, &gso, tun_is_little_endian(tun))) {
this_cpu_inc(tun->pcpu_stats->rx_frame_errors);
kfree_skb(skb);
return -EINVAL;
@@ -1361,15 +1360,12 @@ static ssize_t tun_put_user(struct tun_struct *tun,
}
if (vnet_hdr_sz) {
- struct virtio_net_hdr gso = { 0 }; /* no info leak */
- int ret;
-
+ struct virtio_net_hdr gso;
if (iov_iter_count(iter) < vnet_hdr_sz)
return -EINVAL;
- ret = virtio_net_hdr_from_skb(skb, &gso,
- tun_is_little_endian(tun));
- if (ret) {
+ if (virtio_net_hdr_from_skb(skb, &gso,
+ tun_is_little_endian(tun))) {
struct skb_shared_info *sinfo = skb_shinfo(skb);
pr_err("unexpected GSO type: "
"0x%x, gso_size %d, hdr_len %d\n",
diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
index 1c912f8..74f1e33 100644
--- a/include/linux/virtio_net.h
+++ b/include/linux/virtio_net.h
@@ -98,4 +98,4 @@ static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,
return 0;
}
-#endif /* _LINUX_VIRTIO_BYTEORDER */
+#endif /* _LINUX_VIRTIO_NET_H */
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 11db0d6..09abb88 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1971,8 +1971,6 @@ static unsigned int run_filter(struct sk_buff *skb,
static int __packet_rcv_vnet(const struct sk_buff *skb,
struct virtio_net_hdr *vnet_hdr)
{
- *vnet_hdr = (const struct virtio_net_hdr) { 0 };
-
if (virtio_net_hdr_from_skb(skb, vnet_hdr, vio_le()))
BUG();
@@ -2391,8 +2389,6 @@ static void tpacket_set_protocol(const struct net_device *dev,
static int __packet_snd_vnet_parse(struct virtio_net_hdr *vnet_hdr, size_t len)
{
- unsigned short gso_type = 0;
-
if ((vnet_hdr->flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) &&
(__virtio16_to_cpu(vio_le(), vnet_hdr->csum_start) +
__virtio16_to_cpu(vio_le(), vnet_hdr->csum_offset) + 2 >
@@ -2404,29 +2400,6 @@ static int __packet_snd_vnet_parse(struct virtio_net_hdr *vnet_hdr, size_t len)
if (__virtio16_to_cpu(vio_le(), vnet_hdr->hdr_len) > len)
return -EINVAL;
- if (vnet_hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) {
- switch (vnet_hdr->gso_type & ~VIRTIO_NET_HDR_GSO_ECN) {
- case VIRTIO_NET_HDR_GSO_TCPV4:
- gso_type = SKB_GSO_TCPV4;
- break;
- case VIRTIO_NET_HDR_GSO_TCPV6:
- gso_type = SKB_GSO_TCPV6;
- break;
- case VIRTIO_NET_HDR_GSO_UDP:
- gso_type = SKB_GSO_UDP;
- break;
- default:
- return -EINVAL;
- }
-
- if (vnet_hdr->gso_type & VIRTIO_NET_HDR_GSO_ECN)
- gso_type |= SKB_GSO_TCP_ECN;
-
- if (vnet_hdr->gso_size == 0)
- return -EINVAL;
- }
-
- vnet_hdr->gso_type = gso_type; /* changes type, temporary storage */
return 0;
}
@@ -2449,22 +2422,7 @@ static int packet_snd_vnet_parse(struct msghdr *msg, size_t *len,
static int packet_snd_vnet_gso(struct sk_buff *skb,
struct virtio_net_hdr *vnet_hdr)
{
- if (vnet_hdr->flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) {
- u16 s = __virtio16_to_cpu(vio_le(), vnet_hdr->csum_start);
- u16 o = __virtio16_to_cpu(vio_le(), vnet_hdr->csum_offset);
-
- if (!skb_partial_csum_set(skb, s, o))
- return -EINVAL;
- }
-
- skb_shinfo(skb)->gso_size =
- __virtio16_to_cpu(vio_le(), vnet_hdr->gso_size);
- skb_shinfo(skb)->gso_type = vnet_hdr->gso_type;
-
- /* Header must be checked, and gso_segs computed. */
- skb_shinfo(skb)->gso_type |= SKB_GSO_DODGY;
- skb_shinfo(skb)->gso_segs = 0;
- return 0;
+ return virtio_net_hdr_to_skb(skb, vnet_hdr, vio_le());
}
static int tpacket_fill_skb(struct packet_sock *po, struct sk_buff *skb,
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net-next] netpoll: more efficient locking
From: David Miller @ 2016-11-16 23:32 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1479336890.8455.225.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 16 Nov 2016 14:54:50 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Callers of netpoll_poll_lock() own NAPI_STATE_SCHED
>
> Callers of netpoll_poll_unlock() have BH blocked between
> the NAPI_STATE_SCHED being cleared and poll_lock is released.
>
> We can avoid the spinlock which has no contention, and use cmpxchg()
> on poll_owner which we need to set anyway.
>
> This removes a possible lockdep violation after the cited commit,
> since sk_busy_loop() re-enables BH before calling busy_poll_stop()
>
> Fixes: 217f69743681 ("net: busy-poll: allow preemption in sk_busy_loop()")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next v3 2/3] net: fsl: Allow most drivers to be built with COMPILE_TEST
From: Fengguang Wu @ 2016-11-17 1:38 UTC (permalink / raw)
To: Florian Fainelli
Cc: kbuild-all, netdev, davem, mw, arnd, gregory.clement, Shaohui.Xie
In-Reply-To: <0216ebc6-1889-6ca7-974c-90524ed61651@gmail.com>
On Wed, Nov 16, 2016 at 11:52:45AM -0800, Florian Fainelli wrote:
>On 11/15/2016 07:23 PM, kbuild test robot wrote:
>> Hi Florian,
>>
>> [auto build test WARNING on net-next/master]
>>
>> url: https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-gianfar_ptp-Rename-FS-bit-to-FIPERST/20161116-095805
>> config: sh-allmodconfig (attached as .config)
>> compiler: sh4-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
>> reproduce:
>> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
>> chmod +x ~/bin/make.cross
>> # save the attached .config to linux build tree
>> make.cross ARCH=sh
>>
>> All warnings (new ones prefixed by >>):
>>
>> drivers/net/ethernet/freescale/fsl_pq_mdio.c: In function 'fsl_pq_mdio_remove':
>>>> drivers/net/ethernet/freescale/fsl_pq_mdio.c:498:27: warning: unused variable 'priv' [-Wunused-variable]
>> struct fsl_pq_mdio_priv *priv = bus->priv;
>
>Humm, this looks bogus, the variable is used see below:
>
>> ^~~~
>>
>> vim +/priv +498 drivers/net/ethernet/freescale/fsl_pq_mdio.c
>>
>> 1577ecef drivers/net/fsl_pq_mdio.c Andy Fleming 2009-02-04 482 return 0;
>> 1577ecef drivers/net/fsl_pq_mdio.c Andy Fleming 2009-02-04 483
>> dd3b8a32 drivers/net/ethernet/freescale/fsl_pq_mdio.c Timur Tabi 2012-08-29 484 error:
>> dd3b8a32 drivers/net/ethernet/freescale/fsl_pq_mdio.c Timur Tabi 2012-08-29 485 if (priv->map)
>> b3319b10 drivers/net/fsl_pq_mdio.c Anton Vorontsov 2009-12-30 486 iounmap(priv->map);
>> dd3b8a32 drivers/net/ethernet/freescale/fsl_pq_mdio.c Timur Tabi 2012-08-29 487
>> 1577ecef drivers/net/fsl_pq_mdio.c Andy Fleming 2009-02-04 488 kfree(new_bus);
>> dd3b8a32 drivers/net/ethernet/freescale/fsl_pq_mdio.c Timur Tabi 2012-08-29 489
>> 1577ecef drivers/net/fsl_pq_mdio.c Andy Fleming 2009-02-04 490 return err;
>> 1577ecef drivers/net/fsl_pq_mdio.c Andy Fleming 2009-02-04 491 }
>> 1577ecef drivers/net/fsl_pq_mdio.c Andy Fleming 2009-02-04 492
>> 1577ecef drivers/net/fsl_pq_mdio.c Andy Fleming 2009-02-04 493
>> 5078ac79 drivers/net/ethernet/freescale/fsl_pq_mdio.c Timur Tabi 2012-08-29 494 static int fsl_pq_mdio_remove(struct platform_device *pdev)
>> 1577ecef drivers/net/fsl_pq_mdio.c Andy Fleming 2009-02-04 495 {
>> 5078ac79 drivers/net/ethernet/freescale/fsl_pq_mdio.c Timur Tabi 2012-08-29 496 struct device *device = &pdev->dev;
>> 1577ecef drivers/net/fsl_pq_mdio.c Andy Fleming 2009-02-04 497 struct mii_bus *bus = dev_get_drvdata(device);
>> b3319b10 drivers/net/fsl_pq_mdio.c Anton Vorontsov 2009-12-30 @498 struct fsl_pq_mdio_priv *priv = bus->priv;
>> 1577ecef drivers/net/fsl_pq_mdio.c Andy Fleming 2009-02-04 499
>> 1577ecef drivers/net/fsl_pq_mdio.c Andy Fleming 2009-02-04 500 mdiobus_unregister(bus);
>> 1577ecef drivers/net/fsl_pq_mdio.c Andy Fleming 2009-02-04 501
>> b3319b10 drivers/net/fsl_pq_mdio.c Anton Vorontsov 2009-12-30 502 iounmap(priv->map);
>
>Right here.
>
>What compiler version is this?
Compiler is sh4-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705.
include/asm-generic/io.h conditionally defines iounmap() to be an
empty inline function, which may explain the warning on sh4.
General speaking, it's a false warning. The solution could be to teach
the robot to ignore such 'unused variable' warnings in non-x86 archs.
Thanks,
Fengguang
^ permalink raw reply
* Re: Virtio_net support vxlan encapsulation package TSO offload discuss
From: Zhangming (James, Euler) @ 2016-11-17 1:31 UTC (permalink / raw)
To: Jason Wang, netdev@vger.kernel.org
Cc: Michael S. Tsirkin, Vlad Yasevic, Amnon Ilan
In-Reply-To: <6db6b2a1-edbc-0068-d7d4-e8e15d18edc6@redhat.com>
On 2016年11月15日 11:28, Jason Wang wrote:
>On 2016年11月10日 14:19, Zhangming (James, Euler) wrote:
>> On 2016年11月09日 15:14, Jason Wang wrote:
>>> On 2016年11月08日 19:58, Zhangming (James, Euler) wrote:
>>>> On 2016年11月08日 19:17, Jason Wang wrote:
>>>>
>>>>> On 2016年11月08日 19:13, Jason Wang wrote:
>>>>>> Cc Michael
>>>>>>
>>>>>> On 2016年11月08日 16:34, Zhangming (James, Euler) wrote:
>>>>>>> In container scenario, OVS is installed in the Virtual machine,
>>>>>>> and all the containers connected to the OVS will communicated
>>>>>>> through VXLAN encapsulation.
>>>>>>>
>>>>>>> By now, virtio_net does not support TSO offload for VXLAN
>>>>>>> encapsulated TSO package. In this condition, the performance is
>>>>>>> not good, sender is bottleneck
>>>>>>>
>>>>>>> I googled this scenario, but I didn’t find any information. Will
>>>>>>> virtio_net support VXLAN encapsulation package TSO offload later?
>>>>>>>
>>>>>> Yes and for both sender and receiver.
>>>>>>
>>>>>>> My idea is virtio_net open encapsulated TSO offload, and
>>>>>>> transport encapsulation info to TUN, TUN will parse the info and
>>>>>>> build skb with encapsulation info.
>>>>>>>
>>>>>>> OVS or kernel on the host should be modified to support this.
>>>>>>> Using this method, the TCP performance aremore than 2x as before.
>>>>>>>
>>>>>>> Any advice and suggestions for this idea or new idea will be
>>>>>>> greatly appreciated!
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> James zhang
>>>>>>>
>>>>>> Sounds very good. And we may also need features bits
>>>>>> (VIRTIO_NET_F_GUEST|HOST_GSO_X) for this.
>>>>>>
>>>>>> This is in fact one of items in networking todo list. (See
>>>>>> http://www.linux-kvm.org/page/NetworkingTodo). While at it, we'd
>>>>>> better support not only VXLAN but also other tunnels.
>>>>> Cc Vlad who is working on extending virtio-net headers.
>>>>>
>>>>>> We can start with the spec work, or if you've already had some
>>>>>> bits you can post them as RFC for early review.
>>>>>>
>>>>>> Thanks
>>>> Below is my demo code
>>>> Virtio_net.c
>>>> static int virtnet_probe(struct virtio_device *vdev), add belows codes:
>>>> if (virtio_has_feature(vdev, VIRTIO_NET_F_MRG_RXBUF) || // avoid gso segment, it should be negotiation later, because in the demo I reuse num_buffers.
>>>> virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) {
>>>> dev->hw_enc_features |= NETIF_F_TSO;
>>>> dev->hw_enc_features |= NETIF_F_ALL_CSUM;
>>>> dev->hw_enc_features |= NETIF_F_GSO_UDP_TUNNEL;
>>>> dev->hw_enc_features |= NETIF_F_GSO_UDP_TUNNEL_CSUM;
>>>> dev->hw_enc_features |=
>>>> NETIF_F_GSO_TUNNEL_REMCSUM;
>>>>
>>>> dev->features |= NETIF_F_GSO_UDP_TUNNEL;
>>>> dev->features |= NETIF_F_GSO_UDP_TUNNEL_CSUM;
>>>> dev->features |= NETIF_F_GSO_TUNNEL_REMCSUM;
>>>> }
>>>>
>>>> static int xmit_skb(struct send_queue *sq, struct sk_buff *skb), add
>>>> below to pieces of codes
>>>>
>>>> if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_TUNNEL)
>>>> hdr->hdr.gso_type |= VIRTIO_NET_HDR_GSO_TUNNEL;
>>>> if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_TUNNEL_CSUM)
>>>> hdr->hdr.gso_type |= VIRTIO_NET_HDR_GSO_TUNNEL_CSUM;
>>>> if (skb_shinfo(skb)->gso_type & SKB_GSO_TUNNEL_REMCSUM)
>>>> hdr->hdr.gso_type |=
>>>> VIRTIO_NET_HDR_GSO_TUNNEL_REMCSUM;
>>>>
>>>> if (skb->encapsulation && skb_is_gso(skb)) {
>>>> inner_mac_len = skb_inner_network_header(skb) - skb_inner_mac_header(skb);
>>>> tnl_len = skb_inner_mac_header(skb) - skb_mac_header(skb);
>>>> if ( !(inner_mac_len >> DATA_LEN_SHIFT) && !(tnl_len >> DATA_LEN_SHIFT) ) {
>>>> hdr->hdr.flags |= VIRTIO_NET_HDR_F_ENCAPSULATION;
>>>> hdr->num_buffers = (__virtio16)((inner_mac_len << DATA_LEN_SHIFT) | tnl_len); //we reuse num_buffers for simple , we should add extend member for later.
>>>> } else
>>>> hdr->num_buffers = 0;
>>>> }
>>>>
>>>> Tun.c
>>>> if (memcpy_fromiovecend((void *)&hdr, iv, offset, tun->vnet_hdr_sz)) //read header with negotiation length
>>>> return -EFAULT;
>>>>
>>>> if (hdr.gso_type & VIRTIO_NET_HDR_GSO_TUNNEL) //set tunnel gso info
>>>> skb_shinfo(skb)->gso_type |= SKB_GSO_UDP_TUNNEL;
>>>> if (hdr.gso_type & VIRTIO_NET_HDR_GSO_TUNNEL_CSUM)
>>>> skb_shinfo(skb)->gso_type |= SKB_GSO_UDP_TUNNEL_CSUM;
>>>> if (hdr.gso_type & VIRTIO_NET_HDR_GSO_TUNNEL_REMCSUM)
>>>> skb_shinfo(skb)->gso_type |=
>>>> SKB_GSO_TUNNEL_REMCSUM;
>>>>
>>>> if (hdr.flags & VIRTIO_NET_HDR_F_ENCAPSULATION) { //read tunnel info from header and set to built skb.
>>>> tnl_len = tun16_to_cpu(tun, hdr.num_buffers) & TUN_TNL_LEN_MASK;
>>>> payload_mac_len = tun16_to_cpu(tun, hdr.num_buffers) >> TUN_DATA_LEN_SHIFT;
>>>> mac_len = skb_network_header(skb) - skb_mac_header(skb);
>>>> skb_set_inner_mac_header(skb, tnl_len - mac_len);
>>>> skb_set_inner_network_header(skb, tnl_len + payload_mac_len - mac_len);
>>>> skb->encapsulation = 1;
>>>> }
>>>>
>>>>
>>> Something like this, and you probably need do something more:
>>>
>>> - use net-next.git to generate the patch (for the latest code)
>>> - add feature negotiation
>>> - tun/macvtap/qemu patches for this, you can start with tun/macvtap
>>> patches
>>> - support for all other SKB_GSO_* types which is not supported
>>> - use a new field instead of num_buffers
>>> - a virtio spec patch to describe the support for encapsulation
>>> offload
>>>
>>> Thanks
>> Thank you for your advice, I will start it right now.
>>
>> Thanks
>
>Cool, one more question: while at it, I think you may want to add support for dpdk too?
>
>Thanks
Do you mean that the patch should be compatible with virtio pmd, or give virtio pmd patch?
Thanks
^ permalink raw reply
* Re: [PATCHv2 perf/core 1/2] tools lib bpf: Sync {tools,}/include/uapi/linux/bpf.h
From: Wangnan (F) @ 2016-11-17 1:28 UTC (permalink / raw)
To: Joe Stringer, linux-kernel; +Cc: netdev, ast, daniel, acme
In-Reply-To: <20161116174324.29675-2-joe@ovn.org>
On 2016/11/17 1:43, Joe Stringer wrote:
> The tools version of this header is out of date; update it to the latest
> version from the kernel headers.
>
> Signed-off-by: Joe Stringer <joe@ovn.org>
> ---
> v2: No change.
> ---
> tools/include/uapi/linux/bpf.h | 51 ++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 51 insertions(+)
Acked-by: Wang Nan <wangnan0@huawei.com>
> diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
> index 9e5fc168c8a3..f09c70b97eca 100644
> --- a/tools/include/uapi/linux/bpf.h
> +++ b/tools/include/uapi/linux/bpf.h
> @@ -95,6 +95,7 @@ enum bpf_prog_type {
> BPF_PROG_TYPE_SCHED_ACT,
> BPF_PROG_TYPE_TRACEPOINT,
> BPF_PROG_TYPE_XDP,
> + BPF_PROG_TYPE_PERF_EVENT,
> };
>
> #define BPF_PSEUDO_MAP_FD 1
> @@ -375,6 +376,56 @@ enum bpf_func_id {
> */
> BPF_FUNC_probe_write_user,
>
> + /**
> + * bpf_current_task_under_cgroup(map, index) - Check cgroup2 membership of current task
> + * @map: pointer to bpf_map in BPF_MAP_TYPE_CGROUP_ARRAY type
> + * @index: index of the cgroup in the bpf_map
> + * Return:
> + * == 0 current failed the cgroup2 descendant test
> + * == 1 current succeeded the cgroup2 descendant test
> + * < 0 error
> + */
> + BPF_FUNC_current_task_under_cgroup,
> +
> + /**
> + * bpf_skb_change_tail(skb, len, flags)
> + * The helper will resize the skb to the given new size,
> + * to be used f.e. with control messages.
> + * @skb: pointer to skb
> + * @len: new skb length
> + * @flags: reserved
> + * Return: 0 on success or negative error
> + */
> + BPF_FUNC_skb_change_tail,
> +
> + /**
> + * bpf_skb_pull_data(skb, len)
> + * The helper will pull in non-linear data in case the
> + * skb is non-linear and not all of len are part of the
> + * linear section. Only needed for read/write with direct
> + * packet access.
> + * @skb: pointer to skb
> + * @len: len to make read/writeable
> + * Return: 0 on success or negative error
> + */
> + BPF_FUNC_skb_pull_data,
> +
> + /**
> + * bpf_csum_update(skb, csum)
> + * Adds csum into skb->csum in case of CHECKSUM_COMPLETE.
> + * @skb: pointer to skb
> + * @csum: csum to add
> + * Return: csum on success or negative error
> + */
> + BPF_FUNC_csum_update,
> +
> + /**
> + * bpf_set_hash_invalid(skb)
> + * Invalidate current skb>hash.
> + * @skb: pointer to skb
> + */
> + BPF_FUNC_set_hash_invalid,
> +
> __BPF_FUNC_MAX_ID,
> };
>
^ permalink raw reply
* Re: [PATCH] icmp: Restore resistence to abnormal messages
From: Vicente Jiménez @ 2016-11-17 1:17 UTC (permalink / raw)
To: Florian Westphal
Cc: David Miller, Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, netdev, linux-kernel
In-Reply-To: <20161116011404.GF30581@breakpoint.cc>
On Wed, Nov 16, 2016 at 2:14 AM, Florian Westphal <fw@strlen.de> wrote:
> Vicente Jiménez <googuy@gmail.com> wrote:
>> 1- add warning with pr_warn_ratelimited. I like this idea. I also
>> though about adding some message but I have no kernel experience and I
>> preferred to have just a working solution.
>
> I added this only to show whats happening.
>
> I don't like such printks because end users can't do anything about it.
>
What about using net_dbg_ratelimited macro? it only adds messages if
debug is enabled.
>
>> Finally, both patches decrement current packet by a value: Mine by 2
>> and Florian's by 8 bytes. Both arbitrary values. Personally I prefer
>> to go by small steps. If the small step fails, it just iterate again
>> and with 4 iterations, my patch also decrement the original value by 8
>> bytes (4x2).
>> Basically they are the same but my patch take smaller steps and miss
>> the warning message.
>
> IIRC I chose 8 because connection recovered faster in my case.
>
> I have not experienced this issue again (I dropped the patch from
> my kernel at some point and the connection stalls did not reappear so
> this got fixed elsewhere).
My issue is permanent for now in various locations. We have to
decrease MTU manually on all devices with newer kernels. We don't have
direct access to those abnormal routers because they are managed by a
communication provider that think the network had no problem because
all their Windows machines apparently work perfectly.
--
cheers
vicente
^ permalink raw reply
* Re: Netperf UDP issue with connected sockets
From: Eric Dumazet @ 2016-11-17 0:34 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: Rick Jones, netdev@vger.kernel.org
In-Reply-To: <20161116234022.2bad179b@redhat.com>
On Wed, 2016-11-16 at 23:40 +0100, Jesper Dangaard Brouer wrote:
> Using -R 1 does not seem to help remove __ip_select_ident()
>
> Samples: 56K of event 'cycles', Event count (approx.): 78628132661
> Overhead Command Shared Object Symbol
> + 9.11% netperf [kernel.vmlinux] [k] __ip_select_ident
> + 6.98% netperf [kernel.vmlinux] [k] _raw_spin_lock
> + 6.21% swapper [mlx5_core] [k] mlx5e_poll_tx_cq
> + 5.03% netperf [kernel.vmlinux] [k] copy_user_enhanced_fast_string
> + 4.69% netperf [kernel.vmlinux] [k] __ip_make_skb
> + 4.63% netperf [kernel.vmlinux] [k] skb_set_owner_w
> + 4.15% swapper [kernel.vmlinux] [k] __slab_free
> + 3.80% netperf [mlx5_core] [k] mlx5e_sq_xmit
> + 2.00% swapper [kernel.vmlinux] [k] sock_wfree
> + 1.94% netperf netperf [.] send_data
> + 1.92% netperf netperf [.] send_omni_inner
Check "ss -nu" ?
You will see if sockets are connected (present in ss output or not)
UDP being connected does not prevent __ip_select_ident() being used.
if ((iph->frag_off & htons(IP_DF)) && !skb->ignore_df) {
So you need IP_DF being set, and skb->ignore_df being 0
-> time to try IP_MTU_DISCOVER ;)
^ 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