* Re: [PATCH] net:ethernet:samsung:initialize cur_rx_qnum
From: Francois Romieu @ 2016-12-09 22:42 UTC (permalink / raw)
To: Rayagond Kokatanur; +Cc: siva.kallam, bh74.an, ks.giri, vipul.pandya, netdev
In-Reply-To: <1481285645-6028-1-git-send-email-rayagond.kokatanur@gmail.com>
Rayagond Kokatanur <rayagond.kokatanur@gmail.com> :
> This patch initialize the cur_rx_qnum upon occurence of rx interrupt,
> without this initialization driver will not work with multiple rx queues
> configurations.
>
> NOTE: This patch is not tested on actual hw.
(your patch should include a Signed-off-by)
Imho the driver needs more changes to support multiple rx queues.
- rx interrupt for queue A -> priv->cur_rx_qnum = A
- rx interrupt for queue B -> priv->cur_rx_qnum = B
- rx napi processing -> Err...
Please start turning priv->cur_rx_qnum into a SXGBE_RX_QUEUES sized bitmap.
--
Ueimor
^ permalink raw reply
* Re: [PATCH v2 1/4] net: hix5hd2_gmac: add generic compatible string
From: Rob Herring @ 2016-12-09 22:35 UTC (permalink / raw)
To: Dongpo Li
Cc: mark.rutland, mturquette, sboyd, linux, zhangfei.gao,
yisen.zhuang, salil.mehta, davem, arnd, andrew, xuejiancheng,
benjamin.chenhao, caizhiyong, netdev, devicetree, linux-kernel
In-Reply-To: <1480944481-118803-2-git-send-email-lidongpo@hisilicon.com>
On Mon, Dec 05, 2016 at 09:27:58PM +0800, Dongpo Li wrote:
> The "hix5hd2" is SoC name, add the generic ethernet driver name.
> The "hisi-gemac-v1" is the basic version and "hisi-gemac-v2" adds
> the SG/TXCSUM/TSO/UFO features.
>
> Signed-off-by: Dongpo Li <lidongpo@hisilicon.com>
> ---
> .../devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt | 9 +++++++--
> drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 15 +++++++++++----
> 2 files changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
> index 75d398b..75920f0 100644
> --- a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
> +++ b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
> @@ -1,7 +1,12 @@
> Hisilicon hix5hd2 gmac controller
>
> Required properties:
> -- compatible: should be "hisilicon,hix5hd2-gmac".
> +- compatible: should contain one of the following SoC strings:
> + * "hisilicon,hix5hd2-gemac"
> + * "hisilicon,hi3798cv200-gemac"
> + and one of the following version string:
> + * "hisilicon,hisi-gemac-v1"
> + * "hisilicon,hisi-gemac-v2"
What combinations are valid? I assume both chips don't have both v1 and
v2. 2 SoCs and 2 versions so far, I don't think there is much point to
have the v1 and v2 compatible strings.
> - reg: specifies base physical address(s) and size of the device registers.
> The first region is the MAC register base and size.
> The second region is external interface control register.
> @@ -20,7 +25,7 @@ Required properties:
>
> Example:
> gmac0: ethernet@f9840000 {
> - compatible = "hisilicon,hix5hd2-gmac";
> + compatible = "hisilicon,hix5hd2-gemac", "hisilicon,hisi-gemac-v1";
You can't just change compatible strings.
> reg = <0xf9840000 0x1000>,<0xf984300c 0x4>;
> interrupts = <0 71 4>;
> #address-cells = <1>;
^ permalink raw reply
* Re: Synopsys Ethernet QoS
From: Andy Shevchenko @ 2016-12-09 22:25 UTC (permalink / raw)
To: David Miller
Cc: Joao Pinto, Giuseppe CAVALLARO, lars.persson, rabin.vincent,
netdev, CARLOS.PALMINHA
In-Reply-To: <20161209.104152.1969880574279771010.davem@davemloft.net>
On Fri, Dec 9, 2016 at 5:41 PM, David Miller <davem@davemloft.net> wrote:
> But one thing I am against is changing the driver name for existing
> users. If an existing chip is supported by the stmmac driver for
> existing users, they should still continue to use the "stmmac" driver.
>
> Therefore, if consolidation changes the driver module name for
> existing users, then that is not a good plan at all.
You have at least one supporter here. Though I jumped in to the
discussion very late, not sure if everyone have time to answer to
that.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH iproute2] Makefile: really suppress printing of directories
From: David Ahern @ 2016-12-09 22:05 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20161209125032.57af6e8e@xeon-e3>
On 12/9/16 12:50 PM, Stephen Hemminger wrote:
> On Wed, 7 Dec 2016 12:55:09 -0800
> David Ahern <dsa@cumulusnetworks.com> wrote:
>
>> Makefile adds --no-print-directory to MAKEFLAGS if VERBOSE is not
>> defined however Config always defines VERBOSE. Update the check to
>> whether VERBOSE is 0.
>>
>> Fixes: 57bdf8b76451 ("Make builds default to quiet mode")
>> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
>
> Applied to net-next.
>
> Patch only works with net-next, please label it next time.
>
That does not sound right. The patch this one fixes was applied back in May, and Makefile has only had one other commit against it since.
Regardless, I will add the label to git to default to net-next.
^ permalink raw reply
* [PATCH] net: mlx5: Fix Kconfig help text
From: Christopher Covington @ 2016-12-09 21:53 UTC (permalink / raw)
To: Saeed Mahameed, Matan Barak, Leon Romanovsky,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Christopher Covington
Since the following commit, Infiniband and Ethernet have not been
mutually exclusive.
Fixes: 4aa17b28 mlx5: Enable mutual support for IB and Ethernet
Signed-off-by: Christopher Covington <cov-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
---
drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
index aae4688..521cfdb 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
+++ b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
@@ -18,8 +18,6 @@ config MLX5_CORE_EN
default n
---help---
Ethernet support in Mellanox Technologies ConnectX-4 NIC.
- Ethernet and Infiniband support in ConnectX-4 are currently mutually
- exclusive.
config MLX5_CORE_EN_DCB
bool "Data Center Bridging (DCB) Support"
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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 related
* [PATCH] i40e: don't truncate match_method assignment
From: Jacob Keller @ 2016-12-09 21:39 UTC (permalink / raw)
To: Intel Wired LAN
Cc: Jeffrey Kirsher, netdev, Jacob Keller, Stephen Rothwell,
Bimmy Pujari
The .match_method field is a u8, so we shouldn't be casting to a u16,
and because it is only one byte, we do not need to byte swap anything.
Just assign the value directly. This avoids issues on Big Endian
architectures which would have byte swapped and then incorrectly
truncated the value.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Bimmy Pujari <bimmy.pujari@intel.com>
---
Not sure if this was already in Jeff's queue, but since it's an obvious
fix for the issue found by Stephen, I thought I'd send it out now just
to make sure. Thanks for catching this, and sorry we didn't find the fix
earlier.
drivers/net/ethernet/intel/i40e/i40e_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 69a51a4119d6..6ccf18464339 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -2257,8 +2257,7 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
}
add_list[num_add].queue_number = 0;
/* set invalid match method for later detection */
- add_list[num_add].match_method =
- cpu_to_le16((u16)I40E_AQC_MM_ERR_NO_RES);
+ add_list[num_add].match_method = I40E_AQC_MM_ERR_NO_RES;
cmd_flags |= I40E_AQC_MACVLAN_ADD_PERFECT_MATCH;
add_list[num_add].flags = cpu_to_le16(cmd_flags);
num_add++;
--
2.11.0.rc2.152.g4d04e67
^ permalink raw reply related
* Re: [PATCH net-next v3 1/2] net: dt-bindings: add RGMII TX delay configuration to meson8b-dwmac
From: Rob Herring @ 2016-12-09 21:31 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
mark.rutland-5wv7dgnIgG8, carlo-KA+7E9HrN00dnm+yROfE0A,
khilman-rdvid1DuHRBWk0Htik3J/w, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161202233238.17561-2-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
On Sat, Dec 03, 2016 at 12:32:37AM +0100, Martin Blumenstingl wrote:
> This allows configuring the RGMII TX clock delay. The RGMII clock is
> generated by underlying hardware of the the Meson 8b / GXBB DWMAC glue.
> The configuration depends on the actual hardware (no delay may be
> needed due to the design of the actual circuit, the PHY might add this
> delay, etc.).
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> Tested-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/meson-dwmac.txt | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
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 iproute2] Makefile: really suppress printing of directories
From: Stephen Hemminger @ 2016-12-09 20:50 UTC (permalink / raw)
To: David Ahern; +Cc: netdev
In-Reply-To: <1481144109-11116-1-git-send-email-dsa@cumulusnetworks.com>
On Wed, 7 Dec 2016 12:55:09 -0800
David Ahern <dsa@cumulusnetworks.com> wrote:
> Makefile adds --no-print-directory to MAKEFLAGS if VERBOSE is not
> defined however Config always defines VERBOSE. Update the check to
> whether VERBOSE is 0.
>
> Fixes: 57bdf8b76451 ("Make builds default to quiet mode")
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Applied to net-next.
Patch only works with net-next, please label it next time.
^ permalink raw reply
* Re: [PATCH v2 iproute2/net-next 3/3] tc: flower: support matching on ICMP type and code
From: Stephen Hemminger @ 2016-12-09 20:48 UTC (permalink / raw)
To: Simon Horman; +Cc: netdev, Jiri Pirko
In-Reply-To: <1481118843-10428-4-git-send-email-simon.horman@netronome.com>
On Wed, 7 Dec 2016 14:54:03 +0100
Simon Horman <simon.horman@netronome.com> wrote:
> Support matching on ICMP type and code.
>
> Example usage:
>
> tc qdisc add dev eth0 ingress
>
> tc filter add dev eth0 protocol ip parent ffff: flower \
> indev eth0 ip_proto icmp type 8 code 0 action drop
>
> tc filter add dev eth0 protocol ipv6 parent ffff: flower \
> indev eth0 ip_proto icmpv6 type 128 code 0 action drop
>
> Signed-off-by: Simon Horman <simon.horman@netronome.com>
Applied to net-next
^ permalink raw reply
* Re: [PATCH v2 iproute2/net-next 2/3] tc: flower: introduce enum flower_endpoint
From: Stephen Hemminger @ 2016-12-09 20:47 UTC (permalink / raw)
To: Simon Horman; +Cc: netdev, Jiri Pirko
In-Reply-To: <1481118843-10428-3-git-send-email-simon.horman@netronome.com>
On Wed, 7 Dec 2016 14:54:02 +0100
Simon Horman <simon.horman@netronome.com> wrote:
> Introduce enum flower_endpoint and use it instead of a bool
> as the type for paramatising source and destination.
>
> This is intended to improve read-ability and provide some type
> checking of endpoint parameters.
>
> Signed-off-by: Simon Horman <simon.horman@netronome.com>
Applied to net-next
^ permalink raw reply
* Re: [PATCH v2 iproute2/net-next 1/3] tc: flower: update headers for TCA_FLOWER_KEY_ICMP*
From: Stephen Hemminger @ 2016-12-09 20:47 UTC (permalink / raw)
To: Simon Horman; +Cc: netdev, Jiri Pirko
In-Reply-To: <1481118843-10428-2-git-send-email-simon.horman@netronome.com>
On Wed, 7 Dec 2016 14:54:01 +0100
Simon Horman <simon.horman@netronome.com> wrote:
> These are proposed changes for net-next.
>
> Signed-off-by: Simon Horman <simon.horman@netronome.com>
Picked this up with upstream headers update
^ permalink raw reply
* Re: [PATCH] linux/types.h: enable endian checks for all sparse builds
From: Michael S. Tsirkin @ 2016-12-09 20:45 UTC (permalink / raw)
To: Bart Van Assche
Cc: Madhani, Himanshu, kvm@vger.kernel.org, Neil Armstrong,
David Airlie, linux-remoteproc@vger.kernel.org,
dri-devel@lists.freedesktop.org,
virtualization@lists.linux-foundation.org,
linux-s390@vger.kernel.org, James E.J. Bottomley, Herbert Xu,
linux-scsi@vger.kernel.org, Christoph Hellwig,
v9fs-developer@lists.sourceforge.net, Asias He,
Arnd Bergmann <ar
In-Reply-To: <BLUPR02MB168371E06EFA9AB34AA2C58181870@BLUPR02MB1683.namprd02.prod.outlook.com>
On Fri, Dec 09, 2016 at 03:18:02PM +0000, Bart Van Assche wrote:
> On 12/08/16 22:40, Madhani, Himanshu wrote:
> > We’ll take a look and send patches to resolve these warnings.
>
> Thanks!
>
> Bart.
>
Sounds good. I posted what I have so far so that you can
start from that.
--
MST
^ permalink raw reply
* Re: [PATCH iproute2 net-next] bpf: Fix number of retries when growing log buffer
From: Stephen Hemminger @ 2016-12-09 20:42 UTC (permalink / raw)
To: Thomas Graf; +Cc: netdev, daniel, alexei.starovoitov
In-Reply-To: <fc3866340db64ff7400c14342578b9a104f02fe9.1481103964.git.tgraf@suug.ch>
On Wed, 7 Dec 2016 10:47:59 +0100
Thomas Graf <tgraf@suug.ch> wrote:
> The log buffer is automatically grown when the verifier output does not
> fit into the default buffer size. The number of growing attempts was
> not sufficient to reach the maximum buffer size so far.
>
> Perform 9 iterations to reach max and let the 10th one fail.
>
> j:0 i:65536 max:16777215
> j:1 i:131072 max:16777215
> j:2 i:262144 max:16777215
> j:3 i:524288 max:16777215
> j:4 i:1048576 max:16777215
> j:5 i:2097152 max:16777215
> j:6 i:4194304 max:16777215
> j:7 i:8388608 max:16777215
> j:8 i:16777216 max:16777215
>
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Applied to net-next
^ permalink raw reply
* Re: [PATCH] uio-hv-generic: store physical addresses instead of virtual
From: Arnd Bergmann @ 2016-12-09 20:38 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Greg Kroah-Hartman, Stephen Hemminger, netdev, Haiyang Zhang,
linux-kernel, devel
In-Reply-To: <20161209092844.75b73e8d@xeon-e3>
On Friday, December 9, 2016 9:28:44 AM CET Stephen Hemminger wrote:
> On Fri, 9 Dec 2016 12:44:40 +0100
> Arnd Bergmann <arnd@arndb.de> wrote:
> > Fixes: 95096f2fbd10 ("uio-hv-generic: new userspace i/o driver for VMBus")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Thanks, the code was inherited from outside, and only tested on x86_64.
> Not sure which platform and GCC version generates the warning, was this just W=1?
>
> Acked-by: Stephen Hemminger <sthemmin@microsoft.com>
This was a regular warning with a randconfig build on arm32, but
it happens on any 32-bit architecture when CONFIG_PHYS_ADDR_T_64BIT
is enabled.
Arnd
^ permalink raw reply
* Re: [PATCH net-next v2] dsa:mv88e6xxx: dispose irq mapping for chip->irq
From: Andrew Lunn @ 2016-12-09 18:00 UTC (permalink / raw)
To: Volodymyr Bendiuga
Cc: vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
volodymyr.bendiuga-Re5JQEeQqe8AvxtiuMwx3w, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4388a669-b425-97e0-346b-6b20f7f47f86-qeDNsGSBLoYwFerOooGFRg@public.gmane.org>
On Wed, Dec 07, 2016 at 05:40:12PM +0100, Volodymyr Bendiuga wrote:
> Yes, most of the users of of_irq_get() do not use irq_dispose_mapping().
>
> But some of them do (some irq chips), and I believe the correct way
> of doing this is to
>
> dispose irq mapping, as the description for this function says that
> it unmaps
>
> the irq, which is mapped by of_irq_parse_and_map(). Not disposing
> irq might not make
>
> any affect on most drivers, but some, that get EPROBE_DEFER error do
> need to dispose.
>
> This is what I get when I run the code.
>
> of_irq_put() could be implemented, and it would be a wrapper for
> irq_dispose_mapping()
>
> as I can see it. Should I do it this way?
Hi Volodymyr
Yes, i think having of_irq_put() would be good. It gives some symmetry
to the API.
Andrew
--
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: [PATCHv3 perf/core 5/7] samples/bpf: Switch over to libbpf
From: Joe Stringer @ 2016-12-09 17:59 UTC (permalink / raw)
To: Wangnan (F); +Cc: LKML, ast, Daniel Borkmann, Arnaldo Carvalho de Melo, netdev
In-Reply-To: <77ff1746-6271-0eac-a921-bb852c14a602@huawei.com>
On 8 December 2016 at 21:18, Wangnan (F) <wangnan0@huawei.com> wrote:
>
>
> On 2016/12/9 13:04, Wangnan (F) wrote:
>>
>>
>>
>> On 2016/12/9 10:46, Joe Stringer wrote:
>>
>> [SNIP]
>>
>>> diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
>>> index 62d89d50fcbd..616bd55f3be8 100644
>>> --- a/tools/lib/bpf/Makefile
>>> +++ b/tools/lib/bpf/Makefile
>>> @@ -149,6 +149,8 @@ CMD_TARGETS = $(LIB_FILE)
>>> TARGETS = $(CMD_TARGETS)
>>> +libbpf: all
>>> +
>>
>>
>> Why we need this? I tested this patch without it and it seems to work, and
>> this line causes an extra error:
>> $ pwd
>> /home/wn/kernel/tools/lib/bpf
>> $ make libbpf
>> ...
>> gcc -g -Wall -DHAVE_LIBELF_MMAP_SUPPORT -DHAVE_ELF_GETPHDRNUM_SUPPORT
>> -Wbad-function-cast -Wdeclaration-after-statement -Wformat-security
>> -Wformat-y2k -Winit-self -Wmissing-declarations -Wmissing-prototypes
>> -Wnested-externs -Wno-system-headers -Wold-style-definition -Wpacked
>> -Wredundant-decls -Wshadow -Wstrict-aliasing=3 -Wstrict-prototypes
>> -Wswitch-default -Wswitch-enum -Wundef -Wwrite-strings -Wformat -Werror
>> -Wall -fPIC -I. -I/home/wn/kernel-hydrogen/tools/include
>> -I/home/wn/kernel-hydrogen/tools/arch/x86/include/uapi
>> -I/home/wn/kernel-hydrogen/tools/include/uapi libbpf.c all -o libbpf
>> gcc: error: all: No such file or directory
>> make: *** [libbpf] Error 1
>>
>> Thank you.
>
>
> It is not 'caused' by your patch. 'make libbpf' fails without
> your change because it tries to build an executable from
> libbpf.c, but main() is missing.
>
> I think libbpf should never be used as a make target. Your
> new dependency looks strange.
Thanks for the feedback, I sent a patch to address this on top of perf/core:
https://lkml.org/lkml/2016/12/9/518
^ permalink raw reply
* Re: [PATCH V2 00/22] Broadcom RoCE Driver (bnxt_re)
From: Selvin Xavier @ 2016-12-09 17:52 UTC (permalink / raw)
To: David Miller; +Cc: Doug Ledford, linux-rdma, netdev
In-Reply-To: <20161209.102602.181161966975624956.davem@davemloft.net>
On Fri, Dec 9, 2016 at 8:56 PM, David Miller <davem@davemloft.net> wrote:
> From: Selvin Xavier <selvin.xavier@broadcom.com>
> Date: Thu, 8 Dec 2016 22:47:54 -0800
>
>> This series introduces the RoCE driver for the Broadcom
>> NetXtreme-E 10/25/40/50 gigabit RoCE HCAs.
>> This driver is dependent on the bnxt_en NIC driver and is
>> based on the bnxt_re branch in Doug's repository. bnxt_en changes
>> required for this patch series is already available in this branch.
>>
>> I am preparing a git repository with these changes as per Jason's
>> comment and will share the details later today.
>
> If this is targetted at the net-next tree, it is too late as I've
> closed the net-next tree two nights ago.
>
This patch series is targeting linux-rdma tree. netdev is copied since
this series is dependent on bnxt_en.
Thanks
Selvin
^ permalink raw reply
* [PATCH perf/core] samples/bpf: Drop unnecessary build targets.
From: Joe Stringer @ 2016-12-09 17:51 UTC (permalink / raw)
To: linux-kernel; +Cc: wangnan0, ast, daniel, acme, netdev
Commit f72179ef11db ("samples/bpf: Switch over to libbpf") added these
two makefile changes that were unnecessary for switching samples to use
libbpf. The extra make is already handled by the build dependency, and
libbpf target doesn't build because it lacks main(). Remove these.
Reported-by: Wang Nan <wangnan0@huawei.com>
Signed-off-by: Joe Stringer <joe@ovn.org>
---
samples/bpf/Makefile | 1 -
tools/lib/bpf/Makefile | 2 --
2 files changed, 3 deletions(-)
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 9ffa6a2c061d..60ffc8115b67 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -127,7 +127,6 @@ CLANG ?= clang
# Trick to allow make to be run from this directory
all:
- $(MAKE) -C ../../ tools/lib/bpf/
$(MAKE) -C ../../ $$PWD/
clean:
diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
index 616bd55f3be8..62d89d50fcbd 100644
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@ -149,8 +149,6 @@ CMD_TARGETS = $(LIB_FILE)
TARGETS = $(CMD_TARGETS)
-libbpf: all
-
all: fixdep $(VERSION_FILES) all_cmd
all_cmd: $(CMD_TARGETS)
--
2.10.2
^ permalink raw reply related
* Re: [PATCH] uio-hv-generic: store physical addresses instead of virtual
From: Stephen Hemminger @ 2016-12-09 17:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greg Kroah-Hartman, Stephen Hemminger, netdev, Haiyang Zhang,
linux-kernel, devel
In-Reply-To: <20161209114456.3719619-1-arnd@arndb.de>
On Fri, 9 Dec 2016 12:44:40 +0100
Arnd Bergmann <arnd@arndb.de> wrote:
> gcc warns about the newly added driver when phys_addr_t is wider than
> a pointer:
>
> drivers/uio/uio_hv_generic.c: In function 'hv_uio_mmap':
> drivers/uio/uio_hv_generic.c:71:17: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
> virt_to_phys((void *)info->mem[mi].addr) >> PAGE_SHIFT,
> drivers/uio/uio_hv_generic.c: In function 'hv_uio_probe':
> drivers/uio/uio_hv_generic.c:140:5: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
> = (phys_addr_t)dev->channel->ringbuffer_pages;
> drivers/uio/uio_hv_generic.c:147:3: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
> (phys_addr_t)vmbus_connection.int_page;
> drivers/uio/uio_hv_generic.c:153:3: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
> (phys_addr_t)vmbus_connection.monitor_pages[1];
>
> I can't see why we store a virtual address in a phys_addr_t here,
> as the only user of that variable converts it into a physical
> address anyway, so this moves the conversion to where it logically
> fits according to the types.
>
> Fixes: 95096f2fbd10 ("uio-hv-generic: new userspace i/o driver for VMBus")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks, the code was inherited from outside, and only tested on x86_64.
Not sure which platform and GCC version generates the warning, was this just W=1?
Acked-by: Stephen Hemminger <sthemmin@microsoft.com>
^ permalink raw reply
* Re: [PATCH v2 net-next 0/4] udp: receive path optimizations
From: Tom Herbert @ 2016-12-09 17:13 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jesper Dangaard Brouer, Eric Dumazet, David S . Miller, netdev,
Paolo Abeni
In-Reply-To: <1481302391.4930.201.camel@edumazet-glaptop3.roam.corp.google.com>
On Fri, Dec 9, 2016 at 8:53 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Fri, 2016-12-09 at 08:43 -0800, Tom Herbert wrote:
>>
>>
>
>
>> Are you thinking of allowing unconnected socket to have multiple input
>> queues? Sort of an automatic and transparent SO_REUSEPORT...
>
> It all depends if the user application is using a single thread or
> multiple threads to drain the queue.
>
If they're using multiple threads hopefully there's no reason they
can't use SO_REUSEPORT. Since we should always assume DDOS is
possibility it seems like that should be a general recommendation: If
you have multiple threads listening on a port use SO_REUSEPORT.
> Since we used to grab socket lock in udp_recvmsg(), I guess nobody uses
> multiple threads to read packets from a single socket.
>
That's the hope! So the problem at hand is multiple producer CPUs and
one consumer CPU.
> So heavy users must use SO_REUSEPORT already, not sure what we would
> gain trying to go to a single socket, with the complexity of mem
> charging.
>
I think you're making a good point a the possibility that any
unconnected UDP socket could be subject to an attack, so any use of
unconnected UDP has the potential to become a "heavy user" (in fact
we've seen bring down whole networks before in production). Therefore
the single thread reader case is relevant to consider.
Tom
>
>>
>
>
^ permalink raw reply
* Re: [PATCH v2 net-next 0/4] udp: receive path optimizations
From: Eric Dumazet @ 2016-12-09 16:53 UTC (permalink / raw)
To: Tom Herbert
Cc: Jesper Dangaard Brouer, Eric Dumazet, David S . Miller, netdev,
Paolo Abeni
In-Reply-To: <CALx6S35roMkor_0maXk-SwdXeF4GxBfbxXLEXLGnn6mRRaut6g@mail.gmail.com>
On Fri, 2016-12-09 at 08:43 -0800, Tom Herbert wrote:
>
>
> Are you thinking of allowing unconnected socket to have multiple input
> queues? Sort of an automatic and transparent SO_REUSEPORT...
It all depends if the user application is using a single thread or
multiple threads to drain the queue.
Since we used to grab socket lock in udp_recvmsg(), I guess nobody uses
multiple threads to read packets from a single socket.
So heavy users must use SO_REUSEPORT already, not sure what we would
gain trying to go to a single socket, with the complexity of mem
charging.
>
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: phy: add extension of phy-mode for XLGMII
From: Andrew Lunn @ 2016-12-09 16:39 UTC (permalink / raw)
To: Jie Deng
Cc: Florian Fainelli, davem, netdev, linux-kernel, CARLOS.PALMINHA,
lars.persson, thomas.lendacky
In-Reply-To: <d42cbc77-1409-281a-161f-cf9c85443369@synopsys.com>
On Fri, Dec 09, 2016 at 01:19:07PM +0800, Jie Deng wrote:
>
>
> On 2016/12/9 6:15, Florian Fainelli wrote:
> > On 12/06/2016 07:57 PM, Jie Deng wrote:
> >> This patch adds phy-mode support for Synopsys XLGMAC
> > The functional changes look good, but I would like to see some
> > description of what the XL part stands for here.
> >
> > While you are modifying this, do you also mind submitting a Device Tree
> > specification change:
> >
> > https://www.devicetree.org/specifications/
> >
> > Thanks!
> Thank you for the information.
>
> Currenlty, the XLGMAC is a new IP from Synopsys.
I think Florian wants to know about the IEEE standard or what ever
which defines what the phy-mode XLGMAC is, in the same way there are
standards for RGMII, SGMII, etc.
Andrew
^ permalink raw reply
* Re: [PATCH v2 net-next 0/4] udp: receive path optimizations
From: Eric Dumazet @ 2016-12-09 16:26 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Eric Dumazet, David S . Miller, netdev, Paolo Abeni
In-Reply-To: <20161209170509.25347c9b@redhat.com>
On Fri, 2016-12-09 at 17:05 +0100, Jesper Dangaard Brouer wrote:
> On Thu, 08 Dec 2016 13:13:15 -0800
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > On Thu, 2016-12-08 at 21:48 +0100, Jesper Dangaard Brouer wrote:
> > > On Thu, 8 Dec 2016 09:38:55 -0800
> > > Eric Dumazet <edumazet@google.com> wrote:
> > >
> > > > This patch series provides about 100 % performance increase under flood.
> > >
> > > Could you please explain a bit more about what kind of testing you are
> > > doing that can show 100% performance improvement?
> > >
> > > I've tested this patchset and my tests show *huge* speeds ups, but
> > > reaping the performance benefit depend heavily on setup and enabling
> > > the right UDP socket settings, and most importantly where the
> > > performance bottleneck is: ksoftirqd(producer) or udp_sink(consumer).
> >
> > Right.
> >
> > So here at Google we do not try (yet) to downgrade our expensive
> > Multiqueue Nics into dumb NICS from last decade by using a single queue
> > on them. Maybe it will happen when we can process 10Mpps per core,
> > but we are not there yet ;)
> >
> > So my test is using a NIC, programmed with 8 queues, on a dual-socket
> > machine. (2 physical packages)
> >
> > 4 queues are handled by 4 cpus on socket0 (NUMA node 0)
> > 4 queues are handled by 4 cpus on socket1 (NUMA node 1)
>
> Interesting setup, it will be good to catch cache-line bouncing and
> false-sharing, which the streak of recent patches show ;-) (Hopefully
> such setup are avoided for production).
Well, if you have 100Gbit NIC, and 2 NUMA nodes, what do you suggest
exactly, when jobs run on both nodes ?
If you suggest to remove one package, or force jobs to run on Socket0,
just because the NIC is attached to it, it wont be an option.
Most of the traffic is TCP, so RSS comes nicely here to affine traffic
on one RX queue of the NIC.
Now, if for some reason an innocent UDP socket is the target of a flood,
we need to not make all cpus blocked in a spinlock to eventually queue a
packet.
Be assured that high performance UDP servers use kernel bypass, or
SO_REUSEPORT already. My effort is not targeting these special users,
since they already have good performance.
My effort is to provide some isolation, a bit like the effort I did for
SYN flood attacks (Cpus were all spinning on listener spinlock)
>
>
> > So I explicitly put my poor single thread UDP application in the worst
> > condition, having skbs produced on two NUMA nodes.
>
> On which CPU do you place the single thread UDP application?
No matter in this case. You can either force it to run on a group of
cpu, or let the scheduler choose.
If you let the scheduler choose, then it might help the single tuple
flood attack, since the user thread will be moved on a difference cpu
than the ksoftirqd.
>
> E.g. do you allow it to run on a CPU that also process ksoftirq?
> My experience is that performance is approx half, if ksoftirq and
> UDP-thread share a CPU (after you fixed the softirq issue).
Well, this is exactly what I said earlier. Your choices about cpu
pinning might help or might hurt in different scenarios.
>
>
> > Then my load generator use trafgen, with spoofed UDP source addresses,
> > like a UDP flood would use. Or typical DNS traffic, malicious or not.
>
> I also like trafgen
> https://github.com/netoptimizer/network-testing/tree/master/trafgen
>
> > So I have 8 cpus all trying to queue packets in a single UDP socket.
> >
> > Of course, a real high performance server would use 8 UDP sockets, and
> > SO_REUSEPORT with nice eBPF filter to spread the packets based on the
> > queue/cpu they arrived.
>
> Once the ksoftirq and UDP-threads are silo'ed like that, it should
> basically correspond to the benchmarks of my single queue test,
> multiplied by the number of CPUs/UDP-threads.
Well, if one cpu is shared by the producer and consumer then packets are
hot in caches, so trying to avoid cache line misses as I did is not
really helping.
I optimized the case where we do not assume both parties run on the same
cpu. If you leave process scheduler do its job, then your throughput can
be doubled ;)
Now if for some reason you are stuck with a single CPU, this is a very
different problem, and af_packet might be better.
>
> I think it might be a good idea (for me) to implement such a
> UDP-multi-threaded sink example program (with SO_REUSEPORT and eBPF
> filter) to demonstrate and make sure the stack scales (and every
> time we/I improve single queue performance, the numbers should multiply
> with the scaling). Maybe you already have such an example program?
Well, I do have something using SO_REUSEPORT, but not yet BPF, so not in
a state I can share at this moment.
^ permalink raw reply
* Re: [PATCH V2 00/22] Broadcom RoCE Driver (bnxt_re)
From: Leon Romanovsky @ 2016-12-09 16:27 UTC (permalink / raw)
To: Selvin Xavier; +Cc: dledford, linux-rdma, netdev
In-Reply-To: <1481266096-23331-1-git-send-email-selvin.xavier@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]
On Thu, Dec 08, 2016 at 10:47:54PM -0800, Selvin Xavier wrote:
>
...
> create mode 100644 include/uapi/rdma/bnxt_re_uverbs_abi.h
Please use already established naming format for this file.
It will simplify our future integration with rdma-core library.
Thanks
➜ linux-rdma git:(master) ls -l include/uapi/rdma/*-abi.h
-rw-r--r-- 1 leonro leonro 2291 Dec 7 13:07 include/uapi/rdma/cxgb3-abi.h
-rw-r--r-- 1 leonro leonro 2488 Dec 7 13:07 include/uapi/rdma/cxgb4-abi.h
-rw-r--r-- 1 leonro leonro 2864 Dec 7 13:07 include/uapi/rdma/mlx4-abi.h
-rw-r--r-- 1 leonro leonro 6103 Dec 8 12:52 include/uapi/rdma/mlx5-abi.h
-rw-r--r-- 1 leonro leonro 2932 Dec 7 13:07 include/uapi/rdma/mthca-abi.h
-rw-r--r-- 1 leonro leonro 3380 Dec 7 13:07 include/uapi/rdma/nes-abi.h
-rw-r--r-- 1 leonro leonro 3918 Dec 7 13:07 include/uapi/rdma/ocrdma-abi.h
-rw-r--r-- 1 leonro leonro 2559 Dec 7 13:07 include/uapi/rdma/qedr-abi.h
>
> --
> 2.5.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: stmmac DT property snps,axi_all
From: Alexandre Torgue @ 2016-12-09 16:06 UTC (permalink / raw)
To: Niklas Cassel, Giuseppe Cavallaro; +Cc: netdev
In-Reply-To: <e0362693-4ae9-b3d6-3955-c72df7a1b0c0@axis.com>
Hi Niklas
On 12/09/2016 10:53 AM, Niklas Cassel wrote:
> On 12/09/2016 10:20 AM, Niklas Cassel wrote:
>> On 12/08/2016 02:36 PM, Alexandre Torgue wrote:
>>> Hi Niklas,
>>>
>>> On 12/05/2016 05:18 PM, Niklas Cassel wrote:
>>>> Hello Giuseppe
>>>>
>>>>
>>>> I'm trying to figure out what snps,axi_all is supposed to represent.
>>>>
>>>> It appears that the value is saved, but never used in the code.
>>>>
>>>> Looking at the register specification, I'm guessing that it represents
>>>> Address-Aligned Beats, but there is already the property snps,aal
>>>> for that.
>>> IMO, it is not useful. Indeed AXI_AAL is a read only bit (in AXI bus mode register) and reflects the aal bit in DMA bus register.
>>> As you know we use "snps,aal" to set aal bit in DMA bus register.
>>> So "snps,axi_all" entry seems useless. Let's see with Peppe.
>> Ok, I see. GMAC and GMAC4 is different here.
>>
>> For GMAC4 AAL only exists in DMA_SYS_BUS_MODE.
>> It's not reflected anywhere else.
>>
>> The code is correct in the driver.
>>
>> If snps,axi_all is just created for a read-only register,
>> and it is currently never used in the code,
>> while we have snps,aal, which is correct and works,
>> I guess it should be ok to remove snps,axi_all.
>>
>> I can cook up a patch.
>>
>
> Here we go :)
>
> I will send it as a real patch once net-next reopens.
Thanks ;). Just check with Peppe next week (as he added in the past this
property).
Regards
Alex
>
>
> From defc01cb7c22611b89d9cf1fcae72544092bd62c Mon Sep 17 00:00:00 2001
> From: Niklas Cassel <niklas.cassel@axis.com>
> Date: Fri, 9 Dec 2016 10:27:00 +0100
> Subject: [PATCH net-next] net: stmmac: remove unused duplicate property
> snps,axi_all
>
> For core revision 3.x Address-Aligned Beats is available in two registers.
> The DT property snps,aal was created for AAL in the DMA bus register,
> which is a read/write bit.
> The DT property snps,axi_all was created for AXI_AAL in the AXI bus mode
> register, which is a read only bit that reflects the value of AAL in the
> DMA bus register.
>
> Since the value of snps,axi_all is never used in the driver,
> and since the property was created for a bit that is read only,
> it should be safe to remove the property.
>
> Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
> ---
> Documentation/devicetree/bindings/net/stmmac.txt | 1 -
> drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 -
> include/linux/stmmac.h | 1 -
> 3 files changed, 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
> index 128da752fec9..c3d2fd480a1b 100644
> --- a/Documentation/devicetree/bindings/net/stmmac.txt
> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
> @@ -65,7 +65,6 @@ Optional properties:
> - snps,wr_osr_lmt: max write outstanding req. limit
> - snps,rd_osr_lmt: max read outstanding req. limit
> - snps,kbbe: do not cross 1KiB boundary.
> - - snps,axi_all: align address
> - snps,blen: this is a vector of supported burst length.
> - snps,fb: fixed-burst
> - snps,mb: mixed-burst
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> index 082cd48db6a7..60ba8993c650 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> @@ -121,7 +121,6 @@ static struct stmmac_axi *stmmac_axi_setup(struct platform_device *pdev)
> axi->axi_lpi_en = of_property_read_bool(np, "snps,lpi_en");
> axi->axi_xit_frm = of_property_read_bool(np, "snps,xit_frm");
> axi->axi_kbbe = of_property_read_bool(np, "snps,axi_kbbe");
> - axi->axi_axi_all = of_property_read_bool(np, "snps,axi_all");
> axi->axi_fb = of_property_read_bool(np, "snps,axi_fb");
> axi->axi_mb = of_property_read_bool(np, "snps,axi_mb");
> axi->axi_rb = of_property_read_bool(np, "snps,axi_rb");
> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
> index 266dab9ad782..889e0e9a3f1c 100644
> --- a/include/linux/stmmac.h
> +++ b/include/linux/stmmac.h
> @@ -103,7 +103,6 @@ struct stmmac_axi {
> u32 axi_wr_osr_lmt;
> u32 axi_rd_osr_lmt;
> bool axi_kbbe;
> - bool axi_axi_all;
> u32 axi_blen[AXI_BLEN];
> bool axi_fb;
> bool axi_mb;
>
^ 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