* Re: [PATCH net-next 2/2] flow_dissector: Add limits for encapsulation and EH
From: Hannes Frederic Sowa @ 2017-09-01 13:32 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev, alex.popov
In-Reply-To: <20170831222239.21509-3-tom@quantonium.net>
Tom Herbert <tom@quantonium.net> writes:
> In flow dissector there are no limits to the number of nested
> encapsulations that might be dissected which makes for a nice DOS
> attack. This patch limits for dissecting nested encapsulations
> as well as for dissecting over extension headers.
I was actually more referring to your patch, because the flow dissector
right now is not stack recursive. Your changes would make it doing
recursion on the stack. But it seems something along the lines is anyway
needed. See below.
> Reported-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Signed-off-by: Tom Herbert <tom@quantonium.net>
> ---
> net/core/flow_dissector.c | 48 ++++++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 45 insertions(+), 3 deletions(-)
>
> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
> index 5110180a3e96..1bca748de27d 100644
> --- a/net/core/flow_dissector.c
> +++ b/net/core/flow_dissector.c
> @@ -396,6 +396,35 @@ __skb_flow_dissect_ipv6(const struct sk_buff *skb,
> key_ip->ttl = iph->hop_limit;
> }
>
> +/* Maximum number of nested encapsulations that can be processed in
> + * __skb_flow_dissect
> + */
> +#define MAX_FLOW_DISSECT_ENCAPS 5
I think you can exactly parse one encapsulation layer safely. This is
because you can only keep state on one encapsulation layer protocol
right now.
For example this scenario:
I would like to circumvent tc flower rules that filter based on vlan. I
simply construct a packet looking like:
Ethernet|Vlan|IP|GRE|Ethernet|Vlan|
because we don't recurse in the flow keys either, the second vlan header
would overwrite the information of the first one.
> +
> +static bool skb_flow_dissect_encap_allowed(int *num_encaps, unsigned int *flags)
> +{
> + ++*num_encaps;
> +
> + if (*num_encaps >= MAX_FLOW_DISSECT_ENCAPS) {
> + if (*num_encaps == MAX_FLOW_DISSECT_ENCAPS) {
> + /* Allow one more pass but ignore disregard
> + * further encapsulations
> + */
> + *flags |= FLOW_DISSECTOR_F_STOP_AT_ENCAP;
> + } else {
> + /* Max encaps reached */
> + return false;
> + }
> + }
> +
> + return true;
> +}
> +
> +/* Maximum number of extension headers can be processed in __skb_flow_dissect
> + * per IPv6 packet
> + */
> +#define MAX_FLOW_DISSECT_EH 5
I would at least allow each extension header once, DEST_OPS twice, thus
let's say 12? It is safe in this version because it does not consume
stack space anyway and doesn't update internal state.
> +
> /**
> * __skb_flow_dissect - extract the flow_keys struct and return it
> * @skb: sk_buff to extract the flow from, can be NULL if the rest are specified
> @@ -426,6 +455,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> struct flow_dissector_key_tags *key_tags;
> struct flow_dissector_key_vlan *key_vlan;
> enum flow_dissect_ret fdret;
> + int num_eh, num_encaps = 0;
> bool skip_vlan = false;
> u8 ip_proto = 0;
> bool ret;
> @@ -714,7 +744,9 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> case FLOW_DISSECT_RET_OUT_GOOD:
> goto out_good;
> case FLOW_DISSECT_RET_PROTO_AGAIN:
> - goto proto_again;
> + if (skb_flow_dissect_encap_allowed(&num_encaps, &flags))
> + goto proto_again;
I think you should get the check to the proto_again label. In case you
loop to often you can `goto out_good'.
[...]
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH net-next v2 1/4] net: mvpp2: take advantage of the is_rgmii helper
From: Andrew Lunn @ 2017-09-01 13:33 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, gregory.clement, thomas.petazzoni, nadavh, linux,
linux-kernel, mw, stefanc, miquel.raynal, netdev
In-Reply-To: <20170901090455.32316-2-antoine.tenart@free-electrons.com>
On Fri, Sep 01, 2017 at 11:04:52AM +0200, Antoine Tenart wrote:
> Convert all RGMII checks to use the phy_interface_mode_is_rgmii()
> helper. This is a cosmetic patch.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 2/4] net: mvpp2: make the phy optional
From: Andrew Lunn @ 2017-09-01 13:34 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, gregory.clement, thomas.petazzoni, nadavh, linux,
linux-kernel, mw, stefanc, miquel.raynal, netdev
In-Reply-To: <20170901090455.32316-3-antoine.tenart@free-electrons.com>
On Fri, Sep 01, 2017 at 11:04:53AM +0200, Antoine Tenart wrote:
> There is not necessarily a PHY between the GoP and the physical port.
> However, the driver currently makes the "phy" property mandatory,
> contrary to what is stated in the device tree bindings. This patch makes
> the PHY optional, and aligns the PPv2 driver on its device tree
> documentation. However if a PHY is provided, the GoP link interrupt
> won't be used.
>
> With this patch switches directly connected to the serdes lanes and SFP
> ports on the Armada 8040-db and Armada 7040-db can be used if the link
> interrupt is described in the device tree.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
> Tested-by: Marcin Wojtas <mw@semihalf.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] Documentation/bindings: net: marvell-pp2: add the link interrupt
From: Andrew Lunn @ 2017-09-01 13:35 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, gregory.clement, thomas.petazzoni, nadavh, linux,
linux-kernel, mw, stefanc, miquel.raynal, netdev
In-Reply-To: <20170901090455.32316-5-antoine.tenart@free-electrons.com>
On Fri, Sep 01, 2017 at 11:04:55AM +0200, Antoine Tenart wrote:
> A link interrupt can be described. Document this valid interrupt name.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
> Tested-by: Marcin Wojtas <mw@semihalf.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next] doc: document MSG_ZEROCOPY
From: Willem de Bruijn @ 2017-09-01 13:37 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Network Development, David Miller, Willem de Bruijn
In-Reply-To: <20170901144424.72f9c9e9@redhat.com>
On Fri, Sep 1, 2017 at 8:44 AM, Jesper Dangaard Brouer
<brouer@redhat.com> wrote:
> On Thu, 31 Aug 2017 17:00:13 -0400
> Willem de Bruijn <willemdebruijn.kernel@gmail.com> wrote:
>
>> +More Info
>> +---------
>> +
>> +Much of this document was derived from a longer paper presented at
>> +netdev 2.1. For more in-depth information see that paper and talk,
>> +the excellent reporting over at LWN.net or read the original code.
>> +
>> + paper, slides, video
>> + https://netdevconf.org/2.1/session.html?debruijn
>> +
>> + LWN article
>> + https://lwn.net/Articles/726917/
>> +
>> + patchset
>> + [PATCH net-next v4 0/9] socket sendmsg MSG_ZEROCOPY
>> + https://lwn.net/Articles/730010/
>> + https://www.spinics.net/lists/netdev/msg447552.html
>
> IMHO I think it would be better to use the type links also used in the
> git log. If you look at the kernel git log, then the "Link:" tag have
> the form: http://lkml.kernel.org/r/
> And you can simply append the "Message-Id:" email header.
>
> In this case the link would be:
> http://lkml.kernel.org/r/20170803202945.70750-1-willemdebruijn.kernel@gmail.com
I was not aware of that. Thanks, I'll send a v2.
^ permalink raw reply
* Re: [PATCH v2 3/5] net: mdio-mux: printing driver version is useless
From: Andrew Lunn @ 2017-09-01 13:38 UTC (permalink / raw)
To: Corentin Labbe; +Cc: f.fainelli, netdev, linux-kernel
In-Reply-To: <20170901115604.27513-4-clabbe.montjoie@gmail.com>
On Fri, Sep 01, 2017 at 01:56:02PM +0200, Corentin Labbe wrote:
> Remove the driver version information because this information
> is not useful in an upstream kernel driver.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v2 5/5] net: mdio-mux: fix unbalanced put_device
From: Andrew Lunn @ 2017-09-01 13:38 UTC (permalink / raw)
To: Corentin Labbe; +Cc: f.fainelli, netdev, linux-kernel
In-Reply-To: <20170901115604.27513-6-clabbe.montjoie@gmail.com>
On Fri, Sep 01, 2017 at 01:56:04PM +0200, Corentin Labbe wrote:
> mdio_mux_uninit() call put_device (unconditionally) because of
> of_mdio_find_bus() in mdio_mux_init.
> But of_mdio_find_bus is only called if mux_bus is empty.
> If mux_bus is set, mdio_mux_uninit will print a "refcount_t: underflow"
> trace.
>
> This patch add a get_device in the other branch of "if (mux_bus)".
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH] qlcnic: remove redundant zero check on retries counter
From: Colin King @ 2017-09-01 13:44 UTC (permalink / raw)
To: Harish Patil, Manish Chopra, Dept-GELinuxNICDev, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
At the end of the do while loop the integer counter retries will
always be zero and so the subsequent check to see if it is zero
is always true and therefore redundant. Remove the redundant check
and always return -EIO on this return path. Also unbreak the literal
string in dev_err message to clean up a checkpatch warning.
Detected by CoverityScan, CID#744279 ("Logically dead code")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
index be41e4c77b65..c48a0e2d4d7e 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
@@ -592,13 +592,9 @@ qlcnic_receive_peg_ready(struct qlcnic_adapter *adapter)
} while (--retries);
- if (!retries) {
- dev_err(&adapter->pdev->dev, "Receive Peg initialization not "
- "complete, state: 0x%x.\n", val);
- return -EIO;
- }
-
- return 0;
+ dev_err(&adapter->pdev->dev, "Receive Peg initialization not complete, state: 0x%x.\n",
+ val);
+ return -EIO;
}
int
--
2.14.1
^ permalink raw reply related
* Re: [PATCH] pktgen: add a new sample script for 40G and above link testing
From: Robert Hoo @ 2017-09-01 13:48 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: netdev@vger.kernel.org, davem, tariqt, kyle.leet
In-Reply-To: <20170825111921.061713c8@redhat.com>
On Fri, 2017-08-25 at 11:19 +0200, Jesper Dangaard Brouer wrote:
> (please don't use BCC on the netdev list, replies might miss the list in cc)
>
> Comments inlined below:
>
> On Fri, 25 Aug 2017 10:24:30 +0800 Robert Hoo <robert.hu@intel.com> wrote:
>
> > From: Robert Ho <robert.hu@intel.com>
> >
> > It's hard to benchmark 40G+ network bandwidth using ordinary
> > tools like iperf, netperf. I then tried with pktgen multiqueue sample
> > scripts, but still cannot reach line rate.
>
> The pktgen_sample02_multiqueue.sh does not use burst or skb_cloning.
> Thus, the performance will suffer.
>
> See the samples that use the burst feature:
> pktgen_sample03_burst_single_flow.sh
> pktgen_sample05_flow_per_thread.sh
>
> With the pktgen "burst" feature, I can easily generate 40G. Generating
> 100G is also possible, but often you will hit some HW limits before the
> pktgen limit. I experienced hitting both (1) PCIe Gen3 x8 limit, and (2)
> memory bandwidth limit.
Thanks Jesper for review. Sorry for late reply, I do this part time.
I just tried 'pktgen_sample03_burst_single_flow.sh' and 'pktgen_sample05_flow_per_thread.sh'
cmd:
./pktgen_sample05_flow_per_thread.sh -i ens801 -s 1500 -m 3c:fd:fe:9d:6f:f0 -t 2 -v -x -d 192.168.0.107
./pktgen_sample03_burst_single_flow.sh -i ens801 -s 1500 -m 3c:fd:fe:9d:6f:f0 -t 2 -v -x -d 192.168.0.107
indeed, they can achieve nearly 40G. (though still slightly less than my
script). pktgen_sample03 and pktgen_sample05 can approximately achieve 38xxxMb/sec ~ 39xxxMb/sec;
my script can achieve 40xxxMb/sec ~ 41xxxMb/sec. (threads >= 2)
So a general question: is it still necessary to continue my sample06_numa_awared_queue_irq_affinity work? as sample03
and sample05 already approximately achieved 40G line rate.
>
>
> > I then derived this NUMA awared irq affinity sample script from
> > multi-queue sample one, successfully benchmarked 40G link. I think this can
> > also be useful for 100G reference, though I haven't got device to test.
>
> Okay, so your issue was really related to NUMA irq affinity. I do feel
> that IRQ tuning lives outside the realm of the pktgen scripts, but
> looking closer at your script, I it doesn't look like you change the
> IRQ setting which is good.
Sorry I don't quite understand above. I changed the irq affinities.
See "echo $thread > /proc/irq/${irq_array[$i]}/smp_affinity_list".
You would not like me to change it? I can restore them to original at the end
of the script.
>
> You introduce some helper functions take makes it possible to extract
> NUMA information in the shell script code, really cool. I would like
> to see these functions being integrated into the function.sh file.
Yes, it is doable, if you maintainer think so.
>
>
> > This script simply does:
> > Detect $DEV's NUMA node belonging.
> > Bind each thread (processor from that NUMA node) with each $DEV queue's
> > irq affinity, 1:1 mapping.
> > How many '-t' threads input determines how many queues will be
> > utilized.
> >
> > Tested with Intel XL710 NIC with Cisco 3172 switch.
> >
> > It would be even slightly better if the irqbalance service is turned
> > off outside.
>
> Yes, if you don't turn-off (kill) irqbalance it will move around the
> IRQs behind your back...
Yes; while the experiment result turns out it affects just very little.
>
>
> > Referrences:
> > https://people.netfilter.org/hawk/presentations/LCA2015/net_stack_challenges_100G_LCA2015.pdf
> > http://www.intel.cn/content/dam/www/public/us/en/documents/reference-guides/xl710-x710-performance-tuning-linux-guide.pdf
> >
> > Signed-off-by: Robert Hoo <robert.hu@intel.com>
> > ---
> > ...tgen_sample06_numa_awared_queue_irq_affinity.sh | 132 +++++++++++++++++++++
> > 1 file changed, 132 insertions(+)
> > create mode 100755 samples/pktgen/pktgen_sample06_numa_awared_queue_irq_affinity.sh
> >
> > diff --git a/samples/pktgen/pktgen_sample06_numa_awared_queue_irq_affinity.sh b/samples/pktgen/pktgen_sample06_numa_awared_queue_irq_affinity.sh
> > new file mode 100755
> > index 0000000..f0ee25c
> > --- /dev/null
> > +++ b/samples/pktgen/pktgen_sample06_numa_awared_queue_irq_affinity.sh
> > @@ -0,0 +1,132 @@
> > +#!/bin/bash
> > +#
> > +# Multiqueue: Using pktgen threads for sending on multiple CPUs
> > +# * adding devices to kernel threads which are in the same NUMA node
> > +# * bound devices queue's irq affinity to the threads, 1:1 mapping
> > +# * notice the naming scheme for keeping device names unique
> > +# * nameing scheme: dev@thread_number
> > +# * flow variation via random UDP source port
> > +#
> > +basedir=`dirname $0`
> > +source ${basedir}/functions.sh
> > +root_check_run_with_sudo "$@"
> > +#
> > +# Required param: -i dev in $DEV
> > +source ${basedir}/parameters.sh
> > +
> > +get_iface_node()
> > +{
> > + echo `cat /sys/class/net/$1/device/numa_node`
>
> Here you could use the following shell trick to avoid using "cat":
>
> echo $(</sys/class/net/$1/device/numa_node)
Thanks for teaching. Indeed this is more concise.
>
> It looks like you don't handle the case of -1, which indicate non-NUMA
> system. You need to use something like::
>
> get_iface_node()
> {
> local node=$(</sys/class/net/$1/device/numa_node)
> if [[ $node == -1 ]]; then
> echo 0
> else
> echo $node
> fi
> }
Yes, I can amend in v2.
>
>
> > +}
> > +
> > +get_iface_irqs()
> > +{
> > + local IFACE=$1
> > + local queues="${IFACE}-.*TxRx"
> > +
> > + irqs=$(grep "$queues" /proc/interrupts | cut -f1 -d:)
> > + [ -z "$irqs" ] && irqs=$(grep $IFACE /proc/interrupts | cut -f1 -d:)
> > + [ -z "$irqs" ] && irqs=$(for i in `ls -Ux /sys/class/net/$IFACE/device/msi_irqs` ;\
> > + do grep "$i:.*TxRx" /proc/interrupts | grep -v fdir | cut -f 1 -d : ;\
> > + done)
>
> Nice that you handle all these different methods. I personally look
> in /proc/irq/*/$IFACE*/../smp_affinity_list , like (copy-paste):
>
> echo " --- Align IRQs ---"
> # I've named my NICs ixgbe1 + ixgbe2
> for F in /proc/irq/*/ixgbe*-TxRx-*/../smp_affinity_list; do
> # Extract irqname e.g. "ixgbe2-TxRx-2"
> irqname=$(basename $(dirname $(dirname $F))) ;
> # Substring pattern removal
> hwq_nr=${irqname#*-*-}
> echo $hwq_nr > $F
> #grep . -H $F;
> done
> grep -H . /proc/irq/*/ixgbe*/../smp_affinity_list
>
> Maybe I should switch to use:
> /sys/class/net/$IFACE/device/msi_irqs/*
>
>
> > + [ -z "$irqs" ] && echo "Error: Could not find interrupts for $IFACE"
>
> In the error case you should let the script die. There is a helper
> function for this called "err" (where first arg is the exitcode, which
> is useful to detect the reason your script failed).
Yes, I noticed that helper function and changed some of my original "echo Error"s;
this is a missing in my code clear/tidy work. I can amend in v2.
>
>
> > + echo $irqs
> > +}
>
> > +get_node_cpus()
> > +{
> > + local node=$1
> > + local node_cpu_list
> > + local node_cpu_range_list=`cut -f1- -d, --output-delimiter=" " \
> > + /sys/devices/system/node/node$node/cpulist`
> > +
> > + for cpu_range in $node_cpu_range_list
> > + do
> > + node_cpu_list="$node_cpu_list "`seq -s " " ${cpu_range//-/ }`
> > + done
> > +
> > + echo $node_cpu_list
> > +}
> > +
> > +
> > +# Base Config
> > +DELAY="0" # Zero means max speed
> > +COUNT="20000000" # Zero means indefinitely
> > +[ -z "$CLONE_SKB" ] && CLONE_SKB="0"
> > +
> > +# Flow variation random source port between min and max
> > +UDP_MIN=9
> > +UDP_MAX=109
> > +
> > +node=`get_iface_node $DEV`
> > +irq_array=(`get_iface_irqs $DEV`)
> > +cpu_array=(`get_node_cpus $node`)
>
> Nice trick to generate an array.
>
> > +
> > +[ $THREADS -gt ${#irq_array[*]} -o $THREADS -gt ${#cpu_array[*]} ] && \
> > + err 1 "Thread number $THREADS exceeds: min (${#irq_array[*]},${#cpu_array[*]})"
> > +
> > +# (example of setting default params in your script)
> > +if [ -z "$DEST_IP" ]; then
> > + [ -z "$IP6" ] && DEST_IP="198.18.0.42" || DEST_IP="FD00::1"
> > +fi
> > +[ -z "$DST_MAC" ] && DST_MAC="90:e2:ba:ff:ff:ff"
> > +
> > +# General cleanup everything since last run
> > +pg_ctrl "reset"
> > +
> > +# Threads are specified with parameter -t value in $THREADS
> > +for ((i = 0; i < $THREADS; i++)); do
> > + # The device name is extended with @name, using thread number to
> > + # make then unique, but any name will do.
> > + # Set the queue's irq affinity to this $thread (processor)
> > + thread=${cpu_array[$i]}
> > + dev=${DEV}@${thread}
> > + echo $thread > /proc/irq/${irq_array[$i]}/smp_affinity_list
> > + echo "irq ${irq_array[$i]} is set affinity to `cat /proc/irq/${irq_array[$i]}/smp_affinity_list`"
> > +
> > + # Add remove all other devices and add_device $dev to thread
> > + pg_thread $thread "rem_device_all"
> > + pg_thread $thread "add_device" $dev
> > +
> > + # select queue and bind the queue and $dev in 1:1 relationship
> > + queue_num=$i
> > + echo "queue number is $queue_num"
> > + pg_set $dev "queue_map_min $queue_num"
> > + pg_set $dev "queue_map_max $queue_num"
> > +
> > + # Notice config queue to map to cpu (mirrors smp_processor_id())
> > + # It is beneficial to map IRQ /proc/irq/*/smp_affinity 1:1 to CPU number
> > + pg_set $dev "flag QUEUE_MAP_CPU"
> > +
> > + # Base config of dev
> > + pg_set $dev "count $COUNT"
> > + pg_set $dev "clone_skb $CLONE_SKB"
> > + pg_set $dev "pkt_size $PKT_SIZE"
> > + pg_set $dev "delay $DELAY"
> > +
> > + # Flag example disabling timestamping
> > + pg_set $dev "flag NO_TIMESTAMP"
> > +
> > + # Destination
> > + pg_set $dev "dst_mac $DST_MAC"
> > + pg_set $dev "dst$IP6 $DEST_IP"
> > +
> > + # Setup random UDP port src range
> > + pg_set $dev "flag UDPSRC_RND"
> > + pg_set $dev "udp_src_min $UDP_MIN"
> > + pg_set $dev "udp_src_max $UDP_MAX"
> > +done
> > +
> > +# start_run
> > +echo "Running... ctrl^C to stop" >&2
> > +pg_ctrl "start"
> > +echo "Done" >&2
> > +
> > +# Print results
> > +for ((i = 0; i < $THREADS; i++)); do
> > + thread=${cpu_array[$i]}
> > + dev=${DEV}@${thread}
> > + echo "Device: $dev"
> > + cat /proc/net/pktgen/$dev | grep -A2 "Result:"
> > +done
>
>
>
^ permalink raw reply
* Re: [PATCH] pktgen: add a new sample script for 40G and above link testing
From: Robert Hoo @ 2017-09-01 13:53 UTC (permalink / raw)
To: Tariq Toukan; +Cc: davem, brouer, kyle.leet, netdev
In-Reply-To: <800696cf-477e-52bf-24ae-a0a6c19a5f2d@mellanox.com>
On Sun, 2017-08-27 at 11:25 +0300, Tariq Toukan wrote:
>
> On 25/08/2017 12:26 PM, Robert Hoo wrote:
> > (Sorry for yesterday's wrong sending, I finally fixed my MTA and git
> > send-email settings.)
> >
> > It's hard to benchmark 40G+ network bandwidth using ordinary
> > tools like iperf, netperf (see reference 1).
> > Pktgen, packet generator from Kernel sapce, shall be a candidate.
> > I then tried with pktgen multiqueue sample scripts, but still
> > cannot reach line rate.
>
> Try samples 03 and 04.
Thanks Tariq for review. Sorry for late reply; I do this part time.
Yes, I just tried sample 03 and 04. They can approximately reach 40G
line rate; though still slightly less than my script :) (see my reply
to Jesper).
>
> > I then derived this NUMA awared irq affinity sample script from
> > multi-queue sample one, successfully benchmarked 40G link. I think this can
> > also be useful for 100G reference, though I haven't got device to test yet.
> >
> > This script simply does:
> > Detect $DEV's NUMA node belonging.
> > Bind each thread (processor from that NUMA node) with each $DEV queue's
> > irq affinity, 1:1 mapping.
> > How many '-t' threads input determines how many queues will be
> > utilized.
>
> I agree this is an essential capability.
> This was the main reason I added support for the -f argument.
> Using it, I could choose cores of local NUMA, especially for single
> thread, or when cores of the NUMA are sequential.
Indeed this argument is very helpful.
Sorry I haven't taken it into consideration in v1. I should consider
this, what if user designate '-f'. I can improve this in v2.
>
> >
> > Tested with Intel XL710 NIC with Cisco 3172 switch.
> >
> > It would be even slightly better if the irqbalance service is turned
> > off outside.
> >
> > Referrences:
> > https://people.netfilter.org/hawk/presentations/LCA2015/net_stack_challenges_100G_LCA2015.pdf
> > http://www.intel.cn/content/dam/www/public/us/en/documents/reference-guides/xl710-x710-performance-tuning-linux-guide.pdf
> >
> > Signed-off-by: Robert Hoo <robert.hu@linux.intel.com>
> > ---
>
> Regards,
> Tariq Toukan
^ permalink raw reply
* Re: [PATCH] pktgen: add a new sample script for 40G and above link testing
From: Robert Hoo @ 2017-09-01 13:57 UTC (permalink / raw)
To: Waskiewicz Jr, Peter; +Cc: Jesper Dangaard Brouer, netdev@vger.kernel.org
In-Reply-To: <E0D909EE5BB15A4699798539EA149D7F077932D8@ORSMSX103.amr.corp.intel.com>
On Fri, 2017-08-25 at 14:24 +0000, Waskiewicz Jr, Peter wrote:
> On 8/25/17 5:19 AM, Jesper Dangaard Brouer wrote:
> >>
> >> Tested with Intel XL710 NIC with Cisco 3172 switch.
> >>
> >> It would be even slightly better if the irqbalance service is turned
> >> off outside.
> >
> > Yes, if you don't turn-off (kill) irqbalance it will move around the
> > IRQs behind your back...
>
> Or you can use the --banirq option to irqbalance to ignore your device's
> interrupts as targets for balancing.
Oh, I wasn't aware of this parameter. I will be glad to have try later.
Meanwhile, in my test above, the irqbalance service just affect result
very little.
>
> Cheers,
> -PJ
^ permalink raw reply
* [PATCH 0/2] i40e: fix firmware update
From: Stefan Assmann @ 2017-09-01 14:02 UTC (permalink / raw)
To: intel-wired-lan; +Cc: netdev, davem, jeffrey.t.kirsher, sassmann
The first patch fixes the firmware update which is currently broken and
results in a bad flash (corrupt firmware). Recovery is possible with a
fixed driver.
The second patch reverts a commit that causes the firmware checksum
verification to fail right after a successful flash. This is related to
a recent workqueue change. Haven't gotten to the bottom of this yet, but
for the sake of a smooth firmware update experience let's revert the
commit for now.
Stefan Assmann (2):
i40e: use non-locking i40e_read_nvm_word() function during nvmupdate
Revert "i40e: remove WQ_UNBOUND and the task limit of our workqueue"
drivers/net/ethernet/intel/i40e/i40e_main.c | 12 +++++-------
drivers/net/ethernet/intel/i40e/i40e_nvm.c | 24 ++++++++++++++++++++++--
2 files changed, 27 insertions(+), 9 deletions(-)
--
2.13.5
^ permalink raw reply
* [PATCH 1/2] i40e: use non-locking i40e_read_nvm_word() function during nvmupdate
From: Stefan Assmann @ 2017-09-01 14:02 UTC (permalink / raw)
To: intel-wired-lan; +Cc: netdev, davem, jeffrey.t.kirsher, sassmann
In-Reply-To: <20170901140234.7840-1-sassmann@kpanic.de>
During firmware update the adminq gets locked. Currently during the
update i40e_calc_nvm_checksum() calls i40e_read_nvm_word() which itself
tries to acquire the adminq lock. This fails as the lock is already
taken.
This results in the firmware update to fail, leaving the eeprom in a
corrupt state.
To fix this, introducing __i40e_read_nvm_word() which avoids locking and
replace the calls to i40e_read_nvm_word() in i40e_calc_nvm_checksum()
with the newly introduced function. The change matches the i40e
sourceforge driver as much as possible.
With this in place the firmware update is now working again.
Fixes: ("96a39aed25e6 i40e: Acquire NVM lock before reads on all devices")
Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
---
drivers/net/ethernet/intel/i40e/i40e_nvm.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_nvm.c b/drivers/net/ethernet/intel/i40e/i40e_nvm.c
index 96afef98a08f..aa4cfdc51d2b 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_nvm.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_nvm.c
@@ -322,6 +322,26 @@ i40e_status i40e_read_nvm_word(struct i40e_hw *hw, u16 offset,
}
/**
+ * __i40e_read_nvm_word - Reads nvm word, assumes caller does the locking
+ * @hw: pointer to the HW structure
+ * @offset: offset of the Shadow RAM word to read (0x000000 - 0x001FFF)
+ * @data: word read from the Shadow RAM
+ *
+ * Reads one 16 bit word from the Shadow RAM using the GLNVM_SRCTL register.
+ **/
+static i40e_status __i40e_read_nvm_word(struct i40e_hw *hw,
+ u16 offset, u16 *data)
+{
+ enum i40e_status_code ret_code = 0;
+
+ if (hw->flags & I40E_HW_FLAG_AQ_SRCTL_ACCESS_ENABLE)
+ ret_code = i40e_read_nvm_word_aq(hw, offset, data);
+ else
+ ret_code = i40e_read_nvm_word_srctl(hw, offset, data);
+ return ret_code;
+}
+
+/**
* i40e_read_nvm_buffer_srctl - Reads Shadow RAM buffer via SRCTL register
* @hw: pointer to the HW structure
* @offset: offset of the Shadow RAM word to read (0x000000 - 0x001FFF).
@@ -516,14 +536,14 @@ static i40e_status i40e_calc_nvm_checksum(struct i40e_hw *hw,
data = (u16 *)vmem.va;
/* read pointer to VPD area */
- ret_code = i40e_read_nvm_word(hw, I40E_SR_VPD_PTR, &vpd_module);
+ ret_code = __i40e_read_nvm_word(hw, I40E_SR_VPD_PTR, &vpd_module);
if (ret_code) {
ret_code = I40E_ERR_NVM_CHECKSUM;
goto i40e_calc_nvm_checksum_exit;
}
/* read pointer to PCIe Alt Auto-load module */
- ret_code = i40e_read_nvm_word(hw, I40E_SR_PCIE_ALT_AUTO_LOAD_PTR,
+ ret_code = __i40e_read_nvm_word(hw, I40E_SR_PCIE_ALT_AUTO_LOAD_PTR,
&pcie_alt_module);
if (ret_code) {
ret_code = I40E_ERR_NVM_CHECKSUM;
--
2.13.5
^ permalink raw reply related
* [PATCH 2/2] Revert "i40e: remove WQ_UNBOUND and the task limit of our workqueue"
From: Stefan Assmann @ 2017-09-01 14:02 UTC (permalink / raw)
To: intel-wired-lan; +Cc: netdev, davem, jeffrey.t.kirsher, sassmann
In-Reply-To: <20170901140234.7840-1-sassmann@kpanic.de>
This reverts commit 4d5957cbdecdbb77d24c1465caadd801c07afa4a.
Due to this workqueue change the eeprom check right after flashing
firmware fails, although the flash itself completed successfully.
The error observed looks like this
i40e 0000:88:00.0: eeprom check failed (-62), Tx/Rx traffic disabled
The NIC is fully operational after the flash and even after a cold boot
any follow-up eeprom checks succeed.
This needs to be investigated, but for now it should be more important
to make sure the firmware update works as expected.
Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 6498da8806cb..069b6683e1b0 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -12160,14 +12160,12 @@ static int __init i40e_init_module(void)
i40e_driver_string, i40e_driver_version_str);
pr_info("%s: %s\n", i40e_driver_name, i40e_copyright);
- /* There is no need to throttle the number of active tasks because
- * each device limits its own task using a state bit for scheduling
- * the service task, and the device tasks do not interfere with each
- * other, so we don't set a max task limit. We must set WQ_MEM_RECLAIM
- * since we need to be able to guarantee forward progress even under
- * memory pressure.
+ /* we will see if single thread per module is enough for now,
+ * it can't be any worse than using the system workqueue which
+ * was already single threaded
*/
- i40e_wq = alloc_workqueue("%s", WQ_MEM_RECLAIM, 0, i40e_driver_name);
+ i40e_wq = alloc_workqueue("%s", WQ_UNBOUND | WQ_MEM_RECLAIM, 1,
+ i40e_driver_name);
if (!i40e_wq) {
pr_err("%s: Failed to create workqueue\n", i40e_driver_name);
return -ENOMEM;
--
2.13.5
^ permalink raw reply related
* Re: [PATCH v4 4/5] net: stmmac: dwmac-sun8i: choose internal PHY via phy-is-integrated
From: Rob Herring @ 2017-09-01 14:04 UTC (permalink / raw)
To: Andrew Lunn
Cc: Corentin Labbe, Mark Rutland, Maxime Ripard, Chen-Yu Tsai,
Russell King, Giuseppe CAVALLARO, Alexandre Torgue,
Florian Fainelli, Icenowy Zheng, netdev,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20170831205928.GS22289@lunn.ch>
On Thu, Aug 31, 2017 at 3:59 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Thu, Aug 31, 2017 at 03:18:03PM -0500, Rob Herring wrote:
>> On Sat, Aug 26, 2017 at 11:20:51PM +0200, Andrew Lunn wrote:
>> > Hi Corentin
>> >
>> > I think we have now all agreed this is an mdio-mux, plus it is also an
>> > MII mux. We should represent that in device tree. This patchset does
>> > this. However, as it is now, the mux structure in DT is ignored. All
>> > it does is search for the phy-is-integrated flags and goes on that.
>> >
>> > I made the comment that the device tree representation cannot be
>> > implemented using an MDIO mux driver, because of driver loading
>> > issues. However, the core of the MDIO mux code is just a library,
>> > symbols exported as GPL, free for anything to use.
>> >
>> > What i think should happen is the mdio-mux is implemented inside the
>> > MAC driver, using the mux-core as a library. The device tree structure
>> > of a mix is then reflected within Linux. The mux switch callback is
>> > implemented within the MAC driver. So it can reset the MAC when the
>> > mux is switched. The 'phy-is-integrated' property is then no longer
>> > needed.
>> >
>> > I would suggest a binding something like:
>>
>> This is looks better to me, but...
>>
>> > emac: ethernet@1c0b000 {
>> > compatible = "allwinner,sun8i-h3-emac";
>> > syscon = <&syscon>;
>> > reg = <0x01c0b000 0x104>;
>> > interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
>> > interrupt-names = "macirq";
>> > resets = <&ccu RST_BUS_EMAC>;
>> > reset-names = "stmmaceth";
>> > clocks = <&ccu CLK_BUS_EMAC>;
>> > clock-names = "stmmaceth";
>> > #address-cells = <1>;
>> > #size-cells = <0>;
>> >
>> > phy-handle = <&int_mii_phy>;
>> > phy-mode = "mii";
>> > allwinner,leds-active-low;
>> >
>> > mdio: mdio {
>> > #address-cells = <1>;
>> > #size-cells = <0>;
>> > }
>>
>> Why do you need this node still?
>
> Hi Rob
>
> It might not be needed, depending on how it is implemented. But:
>
> Documentation/devicetree/bindings/net/mdio-mux.txt
>
> It is normal for an mdio bus mux to have a phandle back to the parent
> mdio bus. Also, i think the stmmac driver will only instantiate the
> mdio bus if there is a node for it in the device tree.
You don't have a phandle to the parent mdio bus though.
I think we should allow for both case. The mux could be within the bus
hierarchy. Depends where the controls are. Another alternative someone
will try sooner or later is using the new mux control binding.
Rob
^ permalink raw reply
* [iproute PATCH 2/2] link_gre6: Print the tunnel's tclass setting
From: Phil Sutter @ 2017-09-01 14:08 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20170901140809.13230-1-phil@nwl.cc>
Print the value analogous to flowlabel. While being at it, also break
the overlong lines to not exceed 80 characters boundary.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
ip/link_gre6.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/ip/link_gre6.c b/ip/link_gre6.c
index 447ac5d78ab7b..78b5215c65037 100644
--- a/ip/link_gre6.c
+++ b/ip/link_gre6.c
@@ -462,7 +462,14 @@ static void gre_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
if (flags & IP6_TNL_F_USE_ORIG_FLOWLABEL)
fprintf(f, "flowlabel inherit ");
else
- fprintf(f, "flowlabel 0x%05x ", ntohl(flowinfo & IP6_FLOWINFO_FLOWLABEL));
+ fprintf(f, "flowlabel 0x%05x ",
+ ntohl(flowinfo & IP6_FLOWINFO_FLOWLABEL));
+
+ if (flags & IP6_TNL_F_USE_ORIG_TCLASS)
+ fprintf(f, "tclass inherit ");
+ else
+ fprintf(f, "tclass 0x%02x ",
+ ntohl(flowinfo & IP6_FLOWINFO_TCLASS) >> 20);
if (flags & IP6_TNL_F_RCV_DSCP_COPY)
fprintf(f, "dscp inherit ");
--
2.13.1
^ permalink raw reply related
* [iproute PATCH 0/2] Fix and enhance link_gre6
From: Phil Sutter @ 2017-09-01 14:08 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
Changing a tunnel's flowlabel value was broken if it was set to a
non-zero value before. Since the same problem existed for tclass, patch
1 fixes both instances at once.
Patch 2 enhances 'ip link show' to also print the tclass value. This
change was necessary to properly test the first patch's result.
Phil Sutter (2):
link_gre6: Fix for changing tclass/flowlabel
link_gre6: Print the tunnel's tclass setting
ip/link_gre6.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
--
2.13.1
^ permalink raw reply
* [iproute PATCH 1/2] link_gre6: Fix for changing tclass/flowlabel
From: Phil Sutter @ 2017-09-01 14:08 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20170901140809.13230-1-phil@nwl.cc>
When trying to change tclass or flowlabel of a GREv6 tunnel which has
the respective value set already, the code accidentally bitwise OR'ed
the old and the new value, leading to unexpected results. Fix this by
clearing the relevant bits of flowinfo variable prior to assigning the
new value.
Fixes: af89576d7a8c4 ("iproute2: GRE over IPv6 tunnel support.")
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
ip/link_gre6.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/ip/link_gre6.c b/ip/link_gre6.c
index 4d3d4b54210b9..447ac5d78ab7b 100644
--- a/ip/link_gre6.c
+++ b/ip/link_gre6.c
@@ -288,6 +288,7 @@ get_failed:
else {
if (get_u8(&uval, *argv, 16))
invarg("invalid TClass", *argv);
+ flowinfo &= ~IP6_FLOWINFO_TCLASS;
flowinfo |= htonl((__u32)uval << 20) & IP6_FLOWINFO_TCLASS;
flags &= ~IP6_TNL_F_USE_ORIG_TCLASS;
}
@@ -303,6 +304,7 @@ get_failed:
invarg("invalid Flowlabel", *argv);
if (uval > 0xFFFFF)
invarg("invalid Flowlabel", *argv);
+ flowinfo &= ~IP6_FLOWINFO_FLOWLABEL;
flowinfo |= htonl(uval) & IP6_FLOWINFO_FLOWLABEL;
flags &= ~IP6_TNL_F_USE_ORIG_FLOWLABEL;
}
--
2.13.1
^ permalink raw reply related
* Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running cgroup sock filters
From: Tejun Heo @ 2017-09-01 14:11 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: David Ahern, netdev, daniel, ast, davem
In-Reply-To: <20170901032754.ogqmgqaqp3dwfdbw@ast-mbp>
Hello, Alexei.
On Thu, Aug 31, 2017 at 08:27:56PM -0700, Alexei Starovoitov wrote:
> > > The 2 flags are completely independent. The existing override logic is
> > > unchanged. If a program can not be overridden, then the new recursive
> > > flag is irrelevant.
> >
> > I'm not sure all four combo of the two flags makes sense. Can't we
> > have something simpler like the following?
> >
> > 1. None: No further bpf programs allowed in the subtree.
> >
> > 2. Overridable: If a sub-cgroup installs the same bpf program, this
> > one yields to that one.
> >
> > 3. Recursive: If a sub-cgroup installs the same bpf program, that
> > cgroup program gets run in addition to this one.
> >
> > Note that we can have combinations of overridables and recursives -
> > both allow further programs in the sub-hierarchy and the only
> > distinction is whether that specific program behaves when that
> > happens.
>
> If I understand the proposal correctly in case of:
> A (with recurs) -> B (with override) -> C (with recurse) -> D (with override)
> when something happens in D, you propose to run D,C,A ?
Yes, B gets overridden by C, so the effective progarms are A, C and D.
> With the order of execution from children to parent?
Hmm... I'm not sure about the execution ordering. How these programs
chain would be dependent on the type of the program, right? Would we
be able to use the same chaining order for all types of programs?
> That's a bit a different then what I was proposing with 'multi-prog' flag,
> but the more I think about it the more I like it.
Great.
> In your case detach is sort of transparent to everything around.
> And you would also allow to say 'None' to one of the substrees too, right?
> So something like:
> A (with recurs) -> B (with override) -> C (with recurse) -> D (None) -> E
> would mean that E cannot attach anything and events in E will
> call D->C->A, right?
Yeap.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH net-next 2/3] bpf: Inline LRU map lookup
From: Alexei Starovoitov @ 2017-09-01 14:22 UTC (permalink / raw)
To: Martin KaFai Lau, netdev; +Cc: Daniel Borkmann, kernel-team
In-Reply-To: <20170901062713.1842249-3-kafai@fb.com>
On 8/31/17 11:27 PM, Martin KaFai Lau wrote:
> Inline the lru map lookup to save the cost in making calls to
> bpf_map_lookup_elem() and htab_lru_map_lookup_elem().
>
> Different LRU hash size is tested. The benefit diminishes when
> the cache miss starts to dominate in the bigger LRU hash.
> Considering the change is simple, it is still worth to optimize.
>
> First column: Size of the LRU hash
> Second column: Number of lookups/s
>
> Before:
>> for i in $(seq 9 20); do echo "$((2**i+1)): $(./map_perf_test 1024 1 $((2**i+1)) 10000000 | awk '{print $3}')"; done
> 513: 1132020
> 1025: 1056826
> 2049: 1007024
> 4097: 853298
> 8193: 742723
> 16385: 712600
> 32769: 688142
> 65537: 677028
> 131073: 619437
> 262145: 498770
> 524289: 316695
> 1048577: 260038
>
> After:
>> for i in $(seq 9 20); do echo "$((2**i+1)): $(./map_perf_test 1024 1 $((2**i+1)) 10000000 | awk '{print $3}')"; done
> 513: 1221851
> 1025: 1144695
> 2049: 1049902
> 4097: 884460
> 8193: 773731
> 16385: 729673
> 32769: 721989
> 65537: 715530
> 131073: 671665
> 262145: 516987
> 524289: 321125
> 1048577: 260048
>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next 1/3] bpf: Add lru_hash_lookup performance test
From: Alexei Starovoitov @ 2017-09-01 14:22 UTC (permalink / raw)
To: Martin KaFai Lau, netdev; +Cc: Daniel Borkmann, kernel-team
In-Reply-To: <20170901062713.1842249-2-kafai@fb.com>
On 8/31/17 11:27 PM, Martin KaFai Lau wrote:
> Create a new case to test the LRU lookup performance.
>
> At the beginning, the LRU map is fully loaded (i.e. the number of keys
> is equal to map->max_entries). The lookup is done through key 0
> to num_map_entries and then repeats from 0 again.
>
> This patch also creates an anonymous struct to properly
> name the test params in stress_lru_hmap_alloc() in map_perf_test_kern.c.
>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next 3/3] bpf: Only set node->ref = 1 if it has not been set
From: Alexei Starovoitov @ 2017-09-01 14:22 UTC (permalink / raw)
To: Martin KaFai Lau, netdev; +Cc: Daniel Borkmann, kernel-team
In-Reply-To: <20170901062713.1842249-4-kafai@fb.com>
On 8/31/17 11:27 PM, Martin KaFai Lau wrote:
> This patch writes 'node->ref = 1' only if node->ref is 0.
> The number of lookups/s for a ~1M entries LRU map increased by
> ~30% (260097 to 343313).
>
> Other writes on 'node->ref = 0' is not changed. In those cases, the
> same cache line has to be changed anyway.
>
> First column: Size of the LRU hash
> Second column: Number of lookups/s
>
> Before:
>> echo "$((2**20+1)): $(./map_perf_test 1024 1 $((2**20+1)) 10000000 | awk '{print $3}')"
> 1048577: 260097
>
> After:
>> echo "$((2**20+1)): $(./map_perf_test 1024 1 $((2**20+1)) 10000000 | awk '{print $3}')"
> 1048577: 343313
>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* pull-request: wireless-drivers-next 2017-09-01
From: Kalle Valo @ 2017-09-01 14:34 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's a pull request to net-next for 4.14. If the merge window opens on
Sunday I'm planning to have this as the last one.
Please let me know if there are any problems.
Kalle
The following changes since commit d081a16db80ef7a260fb178aa1199e01f7432625:
net: bcmgenet: Do not return from void function (2017-08-29 22:39:51 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2017-09-01
for you to fetch changes up to eb464d4a8d092a793b97b724cd3cc6eeb229232a:
Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2017-08-31 21:34:22 +0300)
----------------------------------------------------------------
wireless-drivers-next patches for 4.14
Few last patches for 4.14, nothing really major here.
Major changes:
wil6210
* support FW RSSI reporting (by mistake this was accidentally
mentioned already in the previous pull request, but now it's really
included)
* make debugfs optional, adds new Kconfig option CONFIG_WIL6210_DEBUGFS
qtnfmac
* implement 64-bit DMA support
----------------------------------------------------------------
Andy Shevchenko (1):
ath10k: switch to use new generic UUID API
Arvind Yadav (2):
ath6kl: constify usb_device_id
ath9k: constify usb_device_id
Bhumika Goyal (1):
ath9k: make ath_ps_ops structures as const
Bjorn Andersson (1):
wcn36xx: Introduce mutual exclusion of fw configuration
Dan Carpenter (2):
rsi: update some comments
rsi: missing unlocks on error paths
David Spinadel (1):
iwlwifi: mvm: Avoid deferring non bufferable frames
Dedy Lansky (4):
wil6210: support FW RSSI reporting
wil6210: store FW RF calibration result
wil6210: move pre-FW configuration to separate function
wil6210: clear PAL_UNIT_ICR part of device reset
Emmanuel Grumbach (1):
iwlwifi: mvm: bump API to 34 for 8000 and up
Erik Stromdahl (1):
ath10k: sdio: remove unused struct member
Gabriel Craciunescu (1):
ath10k: ath10k_htt_rx_amsdu_allowed() use ath10k_dbg()
Gidon Studinski (2):
wil6210: move vring_idle_trsh definition to wil6210_priv
wil6210: make debugfs compilation optional
Gustavo A. R. Silva (1):
rtlwifi: rtl8723be: fix duplicated code for different branches
Hamad Kadmany (2):
wil6210: protect against invalid length of tx management frame
wil6210: fix interface-up check
Hans de Goede (1):
brcmfmac: Log chip id and revision
Hauke Mehrtens (1):
ath10k: activate user space firmware loading again
Himanshu Jha (1):
rsi: remove memset before memcpy
Kalle Valo (2):
Merge tag 'iwlwifi-next-for-kalle-2017-08-30' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Lazar Alexei (1):
wil6210: align to latest auto generated wmi.h
Liad Kaufman (1):
iwlwifi: fix long debug print
Lior David (3):
wil6210: ratelimit errors in TX/RX interrupts
wil6210: increase connect timeout
wil6210: ensure P2P device is stopped before removing interface
Maya Erez (3):
wil6210: check no_fw_recovery in resume failure recovery
wil6210: add statistics for suspend time
wil6210: notify wiphy on wowlan support
Rakesh Pillai (1):
ath10k: fix memory leak in rx ring buffer allocation
Ryan Hsu (3):
ath10k: fix napi_poll budget overflow
ath10k: add the PCI PM core suspend/resume ops
ath10k: configure and enable the wakeup capability
Sergey Matyukevich (5):
qtnfmac: drop -D__CHECK_ENDIAN from cflags
qtnfmac: module param sanity check
qtnfmac: modify qtnf_map_bar not to return NULL
qtnfmac: fix free_xfer_buffer cleanup
qtnfmac: implement 64-bit dma support
Stanislaw Gruszka (1):
rt2800: fix TX_PIN_CFG setting for non MT7620 chips
drivers/net/wireless/ath/ath10k/core.c | 14 +-
drivers/net/wireless/ath/ath10k/core.h | 2 +-
drivers/net/wireless/ath/ath10k/debug.c | 6 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 19 +-
drivers/net/wireless/ath/ath10k/mac.c | 1 +
drivers/net/wireless/ath/ath10k/pci.c | 50 +-
drivers/net/wireless/ath/ath10k/sdio.c | 4 -
drivers/net/wireless/ath/ath10k/sdio.h | 2 -
drivers/net/wireless/ath/ath10k/wow.c | 14 +
drivers/net/wireless/ath/ath10k/wow.h | 1 +
drivers/net/wireless/ath/ath6kl/usb.c | 2 +-
drivers/net/wireless/ath/ath9k/hif_usb.c | 2 +-
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 2 +-
drivers/net/wireless/ath/ath9k/init.c | 2 +-
drivers/net/wireless/ath/wcn36xx/main.c | 52 +-
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 3 +
drivers/net/wireless/ath/wil6210/Kconfig | 12 +
drivers/net/wireless/ath/wil6210/Makefile | 2 +-
drivers/net/wireless/ath/wil6210/cfg80211.c | 84 ++-
drivers/net/wireless/ath/wil6210/debugfs.c | 27 +-
drivers/net/wireless/ath/wil6210/interrupt.c | 14 +-
drivers/net/wireless/ath/wil6210/main.c | 42 +-
drivers/net/wireless/ath/wil6210/pcie_bus.c | 3 +
drivers/net/wireless/ath/wil6210/pm.c | 27 +-
drivers/net/wireless/ath/wil6210/txrx.c | 6 +-
drivers/net/wireless/ath/wil6210/wil6210.h | 20 +-
drivers/net/wireless/ath/wil6210/wmi.c | 14 +-
drivers/net/wireless/ath/wil6210/wmi.h | 720 ++++++++++++++-------
.../broadcom/brcm80211/brcmfmac/firmware.c | 3 +
drivers/net/wireless/intel/iwlwifi/cfg/8000.c | 4 +-
drivers/net/wireless/intel/iwlwifi/cfg/9000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/cfg/a000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 9 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 9 +-
drivers/net/wireless/quantenna/qtnfmac/Makefile | 4 -
.../net/wireless/quantenna/qtnfmac/pearl/pcie.c | 101 ++-
.../wireless/quantenna/qtnfmac/pearl/pcie_ipc.h | 10 +-
.../quantenna/qtnfmac/pearl/pcie_regs_pearl.h | 1 +
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/dm.c | 8 +-
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 25 +-
drivers/net/wireless/rsi/rsi_91x_sdio.c | 1 -
drivers/net/wireless/rsi/rsi_91x_usb.c | 1 -
43 files changed, 931 insertions(+), 401 deletions(-)
^ permalink raw reply
* [PATCH] mvneta: Driver and hardware supports IPv6 offload, so enable it
From: Andrew Pilloud @ 2017-09-01 14:49 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: netdev, Andrew Pilloud
The mvneta driver and hardware supports IPv6 offload, however it
isn't enabled. Set the NETIF_F_IPV6_CSUM feature to inform the
network layer that this driver can offload IPV6 TCP and UDP
checksums. This change has been tested on an Armada 370 and the
feature support confirmed with several device datasheets
including the Armada XP and Armada 3700.
Signed-off-by: Andrew Pilloud <andrewpilloud@igneoussystems.com>
---
drivers/net/ethernet/marvell/mvneta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 0aab74c2a209..369ad971b42a 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -4332,7 +4332,7 @@ static int mvneta_probe(struct platform_device *pdev)
}
}
- dev->features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_TSO;
+ dev->features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | NETIF_F_TSO;
dev->hw_features |= dev->features;
dev->vlan_features |= dev->features;
dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
--
2.11.0
^ permalink raw reply related
* [PATCH net-next] bpf: Collapse offset checks in sock_filter_is_valid_access
From: David Ahern @ 2017-09-01 15:18 UTC (permalink / raw)
To: netdev, daniel; +Cc: David Ahern
Make sock_filter_is_valid_access consistent with other is_valid_access
helpers.
Requested-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David Ahern <dsahern@gmail.com>
---
net/core/filter.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index 9dad3e7e2e10..f9add024d92f 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -3468,9 +3468,7 @@ static bool sock_filter_is_valid_access(int off, int size,
if (type == BPF_WRITE) {
switch (off) {
case offsetof(struct bpf_sock, bound_dev_if):
- break;
case offsetof(struct bpf_sock, mark):
- break;
case offsetof(struct bpf_sock, priority):
break;
default:
--
2.1.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox