* Re: DSA vs. SWTICHDEV ?
From: Andrew Lunn @ 2016-12-01 17:31 UTC (permalink / raw)
To: Murali Karicheri
Cc: Joakim Tjernlund, netdev@vger.kernel.org, Roger Quadros,
Grygorii Strashko
In-Reply-To: <584054C4.1010809@ti.com>
Hi Murali
> 2. Switch mode where it implements a simple Ethernet switch. Currently
> it doesn't have address learning capability, but in future it
> can.
If it does not have address learning capabilities, does it act like a
plain old hub? What comes in one port goes out all others?
Or can you do the learning in software on the host and program tables,
which the hardware then uses?
> 3. Switch with HSR/PRP offload where it provides HSR/PRP protocol
> support and cut through switch.
>
> So a device need to function in one of the modes. A a regular Ethernet
> driver that provides two network devices, one per port, and switchdev
> for each physical port (in switch mode) will look ideal in this case.
Yes, this seems the right model to use.
Andrew
^ permalink raw reply
* Re: [PATCH] mm: page_alloc: High-order per-cpu page allocator v3
From: Jesper Dangaard Brouer @ 2016-12-01 17:34 UTC (permalink / raw)
To: Mel Gorman
Cc: Andrew Morton, Christoph Lameter, Michal Hocko, Vlastimil Babka,
Johannes Weiner, Linux-MM, Linux-Kernel, Rick Jones, Paolo Abeni,
brouer, netdev@vger.kernel.org, Hannes Frederic Sowa
In-Reply-To: <20161130163520.hg7icdflagmvarbr@techsingularity.net>
(Cc. netdev, we might have an issue with Paolo's UDP accounting and
small socket queues)
On Wed, 30 Nov 2016 16:35:20 +0000
Mel Gorman <mgorman@techsingularity.net> wrote:
> > I don't quite get why you are setting the socket recv size
> > (with -- -s and -S) to such a small number, size + 256.
> >
>
> Maybe I missed something at the time I wrote that but why would it
> need to be larger?
Well, to me it is quite obvious that we need some queue to avoid packet
drops. We have two processes netperf and netserver, that are sending
packets between each-other (UDP_STREAM mostly netperf -> netserver).
These PIDs are getting scheduled and migrated between CPUs, and thus
does not get executed equally fast, thus a queue is need absorb the
fluctuations.
The network stack is even partly catching your config "mistake" and
increase the socket queue size, so we minimum can handle one max frame
(due skb "truesize" concept approx PAGE_SIZE + overhead).
Hopefully for localhost testing a small queue should hopefully not
result in packet drops. Testing... ups, this does result in packet
drops.
Test command extracted from mmtests, UDP_STREAM size 1024:
netperf-2.4.5-installed/bin/netperf -t UDP_STREAM -l 60 -H 127.0.0.1 \
-- -s 1280 -S 1280 -m 1024 -M 1024 -P 15895
UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0)
port 15895 AF_INET to 127.0.0.1 (127.0.0.1) port 15895 AF_INET
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
4608 1024 60.00 50024301 0 6829.98
2560 60.00 46133211 6298.72
Dropped packets: 50024301-46133211=3891090
To get a better drop indication, during this I run a command, to get
system-wide network counters from the last second, so below numbers are
per second.
$ nstat > /dev/null && sleep 1 && nstat
#kernel
IpInReceives 885162 0.0
IpInDelivers 885161 0.0
IpOutRequests 885162 0.0
UdpInDatagrams 776105 0.0
UdpInErrors 109056 0.0
UdpOutDatagrams 885160 0.0
UdpRcvbufErrors 109056 0.0
IpExtInOctets 931190476 0.0
IpExtOutOctets 931189564 0.0
IpExtInNoECTPkts 885162 0.0
So, 885Kpps but only 776Kpps delivered and 109Kpps drops. See
UdpInErrors and UdpRcvbufErrors is equal (109056/sec). This drop
happens kernel side in __udp_queue_rcv_skb[1], because receiving
process didn't empty it's queue fast enough see [2].
Although upstream changes are coming in this area, [2] is replaced with
__udp_enqueue_schedule_skb, which I actually tested with... hmm
Retesting with kernel 4.7.0-baseline+ ... show something else.
To Paolo, you might want to look into this. And it could also explain why
I've not see the mentioned speedup by mm-change, as I've been testing
this patch on top of net-next (at 93ba2222550) with Paolo's UDP changes.
netperf-2.4.5-installed/bin/netperf -t UDP_STREAM -l 60 -H 127.0.0.1 \
-- -s 1280 -S 1280 -m 1024 -M 1024 -P 15895
UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 15895
AF_INET to 127.0.0.1 (127.0.0.1) port 15895 AF_INET
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
4608 1024 60.00 47248301 0 6450.97
2560 60.00 47245030 6450.52
Only dropped 47248301-47245030=3271
$ nstat > /dev/null && sleep 1 && nstat
#kernel
IpInReceives 810566 0.0
IpInDelivers 810566 0.0
IpOutRequests 810566 0.0
UdpInDatagrams 810468 0.0
UdpInErrors 99 0.0
UdpOutDatagrams 810566 0.0
UdpRcvbufErrors 99 0.0
IpExtInOctets 852713328 0.0
IpExtOutOctets 852713328 0.0
IpExtInNoECTPkts 810563 0.0
And nstat is also much better with only 99 drop/sec.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
[1] http://lxr.free-electrons.com/source/net/ipv4/udp.c?v=4.8#L1454
[2] http://lxr.free-electrons.com/source/net/core/sock.c?v=4.8#L413
Extra: with net-next at 93ba2222550
If I use netperf default socket queue, then there is not a single
packet drop:
netperf-2.4.5-installed/bin/netperf -t UDP_STREAM -l 60 -H 127.0.0.1
-- -m 1024 -M 1024 -P 15895
UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0)
port 15895 AF_INET to 127.0.0.1 (127.0.0.1) port 15895 AF_INET
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
212992 1024 60.00 48485642 0 6619.91
212992 60.00 48485642 6619.91
$ nstat > /dev/null && sleep 1 && nstat
#kernel
IpInReceives 821723 0.0
IpInDelivers 821722 0.0
IpOutRequests 821723 0.0
UdpInDatagrams 821722 0.0
UdpOutDatagrams 821722 0.0
IpExtInOctets 864457856 0.0
IpExtOutOctets 864458908 0.0
IpExtInNoECTPkts 821729 0.0
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v2] sh_eth: remove unchecked interrupts
From: Sergei Shtylyov @ 2016-12-01 17:36 UTC (permalink / raw)
To: Chris Brandt, David Miller
Cc: Simon Horman, Geert Uytterhoeven, netdev, linux-renesas-soc
In-Reply-To: <20161201140642.28583-1-chris.brandt@renesas.com>
On 12/01/2016 05:06 PM, Chris Brandt wrote:
> When streaming a lot of data and the RZ can't keep up, some status bits
> will get set that are not being checked or cleared which cause the
> following messages and the Ethernet driver to stop working. This
> patch fixes that issue.
>
> irq 21: nobody cared (try booting with the "irqpoll" option)
> handlers:
> [<c036b71c>] sh_eth_interrupt
> Disabling IRQ #21
>
> Fixes: db893473d313a4ad ("sh_eth: Add support for r7s72100")
> Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* Re: Regression: [PATCH] mlx4: give precise rx/tx bytes/packets counters
From: Eric Dumazet @ 2016-12-01 17:36 UTC (permalink / raw)
To: Saeed Mahameed; +Cc: Jesper Dangaard Brouer, David Miller, netdev, Tariq Toukan
In-Reply-To: <1480608517.18162.313.camel@edumazet-glaptop3.roam.corp.google.com>
On Thu, 2016-12-01 at 08:08 -0800, Eric Dumazet wrote:
> On Thu, 2016-12-01 at 07:55 -0800, Eric Dumazet wrote:
>
> > So removing the spinlock is doable, but needs to add a new parameter
> > to mlx4_en_fold_software_stats() and call netdev_stats_to_stats64()
> > before mlx4_en_fold_software_stats(dev)
>
> Untested patch would be :
>
> drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 2 -
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 10 +----
> drivers/net/ethernet/mellanox/mlx4/en_port.c | 24 +++++++++-----
> drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 3 +
> 4 files changed, 23 insertions(+), 16 deletions(-)
The patch is wrong, since priv->port_up could change to false while we
are running and using the about to be deleted tx/rx rings.
So the only safe thing to do is to remove the _bh suffix.
Not worth trying to avoid taking a spinlock in this code.
^ permalink raw reply
* Re: [PATCH v2] sh_eth: remove unchecked interrupts
From: Sergei Shtylyov @ 2016-12-01 17:37 UTC (permalink / raw)
To: Geert Uytterhoeven, Chris Brandt
Cc: David Miller, Simon Horman, Geert Uytterhoeven,
netdev@vger.kernel.org, Linux-Renesas
In-Reply-To: <CAMuHMdU80M2qcK74YgPC8SZ20tNcKrZhj7MXo_Ok=6m4Aa0=-w@mail.gmail.com>
On 12/01/2016 05:42 PM, Geert Uytterhoeven wrote:
>> --- a/drivers/net/ethernet/renesas/sh_eth.c
>> +++ b/drivers/net/ethernet/renesas/sh_eth.c
>> @@ -518,7 +518,7 @@ static struct sh_eth_cpu_data r7s72100_data = {
>>
>> .ecsr_value = ECSR_ICD,
>> .ecsipr_value = ECSIPR_ICDIP,
>> - .eesipr_value = 0xff7f009f,
>> + .eesipr_value = 0xe77f009f,
>
> Comment not directly related to the merits of this patch: the EESIPR bit
> definitions seem to be identical to those for EESR, so we can get rid of the
> hardcoded values here?
Do you mean using the @define's? We have EESIPR bits also declared, see
enum DMAC_IM_BIT,
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v2] sh_eth: remove unchecked interrupts
From: Sergei Shtylyov @ 2016-12-01 17:40 UTC (permalink / raw)
To: Chris Brandt, David Miller
Cc: Simon Horman, Geert Uytterhoeven, netdev, linux-renesas-soc
In-Reply-To: <228704e3-fe33-1c1f-61a1-7db451af5faf@cogentembedded.com>
On 12/01/2016 08:36 PM, Sergei Shtylyov wrote:
>> When streaming a lot of data and the RZ can't keep up, some status bits
>> will get set that are not being checked or cleared which cause the
>> following messages and the Ethernet driver to stop working. This
>> patch fixes that issue.
>>
>> irq 21: nobody cared (try booting with the "irqpoll" option)
>> handlers:
>> [<c036b71c>] sh_eth_interrupt
>> Disabling IRQ #21
>>
>> Fixes: db893473d313a4ad ("sh_eth: Add support for r7s72100")
>> Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
>
> Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
One thing you've missed so far is mentioning R7S72100 (RZ/A1) in the
subject. This driver supports many SoCs, you're only fixing one of them...
MBR, Sergei
^ permalink raw reply
* [PATCH net v2] net: bcmgenet: Utilize correct struct device for all DMA operations
From: Florian Fainelli @ 2016-12-01 17:45 UTC (permalink / raw)
To: netdev; +Cc: davem, pgynther, jaedon.shin, opendmb, Florian Fainelli
From: Florian Fainelli <f.fainelli@gmail.com>
__bcmgenet_tx_reclaim() and bcmgenet_free_rx_buffers() are not using the
same struct device during unmap that was used for the map operation,
which makes DMA-API debugging warn about it. Fix this by always using
&priv->pdev->dev throughout the driver, using an identical device
reference for all map/unmap calls.
Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index 4464bc5db934..a4e60e56c14f 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -1172,6 +1172,7 @@ static unsigned int __bcmgenet_tx_reclaim(struct net_device *dev,
struct bcmgenet_tx_ring *ring)
{
struct bcmgenet_priv *priv = netdev_priv(dev);
+ struct device *kdev = &priv->pdev->dev;
struct enet_cb *tx_cb_ptr;
struct netdev_queue *txq;
unsigned int pkts_compl = 0;
@@ -1199,13 +1200,13 @@ static unsigned int __bcmgenet_tx_reclaim(struct net_device *dev,
if (tx_cb_ptr->skb) {
pkts_compl++;
bytes_compl += GENET_CB(tx_cb_ptr->skb)->bytes_sent;
- dma_unmap_single(&dev->dev,
+ dma_unmap_single(kdev,
dma_unmap_addr(tx_cb_ptr, dma_addr),
dma_unmap_len(tx_cb_ptr, dma_len),
DMA_TO_DEVICE);
bcmgenet_free_cb(tx_cb_ptr);
} else if (dma_unmap_addr(tx_cb_ptr, dma_addr)) {
- dma_unmap_page(&dev->dev,
+ dma_unmap_page(kdev,
dma_unmap_addr(tx_cb_ptr, dma_addr),
dma_unmap_len(tx_cb_ptr, dma_len),
DMA_TO_DEVICE);
@@ -1775,6 +1776,7 @@ static int bcmgenet_alloc_rx_buffers(struct bcmgenet_priv *priv,
static void bcmgenet_free_rx_buffers(struct bcmgenet_priv *priv)
{
+ struct device *kdev = &priv->pdev->dev;
struct enet_cb *cb;
int i;
@@ -1782,7 +1784,7 @@ static void bcmgenet_free_rx_buffers(struct bcmgenet_priv *priv)
cb = &priv->rx_cbs[i];
if (dma_unmap_addr(cb, dma_addr)) {
- dma_unmap_single(&priv->dev->dev,
+ dma_unmap_single(kdev,
dma_unmap_addr(cb, dma_addr),
priv->rx_buf_len, DMA_FROM_DEVICE);
dma_unmap_addr_set(cb, dma_addr, 0);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net v2] tipc: check minimum bearer MTU
From: Michal Kubecek @ 2016-12-01 17:52 UTC (permalink / raw)
To: Ben Hutchings
Cc: Jon Maloy, Ying Xue, David S. Miller, tipc-discussion, netdev,
linux-kernel, Qian Zhang
In-Reply-To: <1480608678.16599.94.camel@decadent.org.uk>
On Thu, Dec 01, 2016 at 04:11:18PM +0000, Ben Hutchings wrote:
> On Thu, 2016-12-01 at 12:02 +0100, Michal Kubecek wrote:
> [...]
> > +/* check if device MTU is sufficient for tipc headers */
> > +static inline bool tipc_check_mtu(struct net_device *dev, unsigned int reserve)
> > +{
> > + if (dev->mtu >= TIPC_MIN_BEARER_MTU + reserve)
> > + return false;
> > + netdev_warn(dev, "MTU too low for tipc bearer\n");
> > + return true;
> > +}
> [...]
>
> The comment says "check if ... sufficient" but the return value
> indicates the opposite. Could you make these consistent?
Good point. I suppose renaming the function to e.g. tipc_mtu_bad() (and
rewording the commment accordingly) would also make the code more
readable without looking at the definition.
I'll wait for other comments and send v3 tomorrow.
> Other than that, this looks OK to me. I haven't tested any version as
> I don't know how to use TIPC.
I checked that the patch doesn't allow enabling a bearer on top of
device with insufficient MTU and it does for sufficient (100/128), both
in eth and udp case. I also checked that lowering MTU under 100 in eth
case disables attached bearer. I didn't run any deeper test like sending
an actual traffic but the patch shouldn't affect that.
Michal Kubecek
^ permalink raw reply
* Re: [RFC PATCH net-next v2] ipv6: implement consistent hashing for equal-cost multipath routing
From: Roopa Prabhu @ 2016-12-01 17:55 UTC (permalink / raw)
To: David Lebrun; +Cc: Hannes Frederic Sowa, netdev@vger.kernel.org
In-Reply-To: <583E8646.2010402@uclouvain.be>
On Tue, Nov 29, 2016 at 11:56 PM, David Lebrun
<david.lebrun@uclouvain.be> wrote:
> On 11/30/2016 04:52 AM, Hannes Frederic Sowa wrote:
>
>> Also please convert the sysctl to a netlink attribute if you pursue this
>> because if I change the sysctl while my quagga is hammering the routing
>> table I would like to know which nodes allocate what amount of memory.
>
> Yes, that was the idea.
>
I think Its best for it to be a global setting, and thats why sysctl
seems like the best way (unless there are other ways to set this
globally via rtnetlink). If it helps, most hw switch vendors
supporting this feature also provide a globally tunable knob and it is
not on by default.
^ permalink raw reply
* Re: [PATCH v7 net-next 2/6] bpf: Add new cgroup attach type to enable sock modifications
From: Alexei Starovoitov @ 2016-12-01 16:56 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, daniel, ast, daniel, maheshb, tgraf
In-Reply-To: <1480610888-31082-3-git-send-email-dsa@cumulusnetworks.com>
On Thu, Dec 01, 2016 at 08:48:04AM -0800, David Ahern wrote:
> Add new cgroup based program type, BPF_PROG_TYPE_CGROUP_SOCK. Similar to
> BPF_PROG_TYPE_CGROUP_SKB programs can be attached to a cgroup and run
> any time a process in the cgroup opens an AF_INET or AF_INET6 socket.
> Currently only sk_bound_dev_if is exported to userspace for modification
> by a bpf program.
>
> This allows a cgroup to be configured such that AF_INET{6} sockets opened
> by processes are automatically bound to a specific device. In turn, this
> enables the running of programs that do not support SO_BINDTODEVICE in a
> specific VRF context / L3 domain.
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* Re: [flamebait] xdp, well meaning but pointless
From: Tom Herbert @ 2016-12-01 18:02 UTC (permalink / raw)
To: Florian Westphal; +Cc: Linux Kernel Network Developers
In-Reply-To: <CALx6S35R_ZStV=DbD-7Gf_y5xXqQq113_6m5p-p0GQfv46v0Ow@mail.gmail.com>
On Thu, Dec 1, 2016 at 10:01 AM, Tom Herbert <tom@herbertland.com> wrote:
>
>
> On Thu, Dec 1, 2016 at 1:11 AM, Florian Westphal <fw@strlen.de> wrote:
>>
>> [ As already mentioned in my reply to Tom, here is
>> the xdp flamebait/critique ]
>>
>> Lots of XDP related patches started to appear on netdev.
>> I'd prefer if it would stop...
>>
>> To me XDP combines all disadvantages of stack bypass solutions like dpdk
>> with the disadvantages of kernel programming with a more limited
>> instruction set and toolchain.
>>
>> Unlike XDP userspace bypass (dpdk et al) allow use of any programming
>> model or language you want (including scripting languages), which
>> makes things a lot easier, e.g. garbage collection, debuggers vs.
>> crash+vmcore+printk...
>>
>> I have heared the argument that these restrictions that come with
>> XDP are great because it allows to 'limit what users can do'.
>>
>> Given existence of DPDK/netmap/userspace bypass is a reality, this is
>> a very weak argument -- why would anyone pick XDP over a dpdk/netmap
>> based solution?
>
Because, we've seen time an time again that attempts to bypass the
stack and run parallel stacks under the banner of "the kernel is too
slow" does not scale for large deployment. We've seen this with RDMA,
TOE, OpenOnload, and we'll see this for DPDK, FD.io, VPP and whatever
else people are going to dream up. If I have a couple hundred machines
running a single application like the HFT guys do, then sure I'd
probably look into such solutions. But when I have datacenters with
100Ks running an assortment of applications even contemplating the
possibility of deploying a parallel stacks gives me headache. We need
to consider an seemingly endless list of security issues,
manageability. robustness, protocol compatibility, etc. I really have
little interest in bringing a huge pile of 3rd party code that I have
to support, and I definitely have no interest in constantly replacing
all of my hardware to get the latest and greatest support for these
offloads as vendors leak them out. Given a choice between buying into
some kernel bypass solution versus hacking Linux a little bit to carve
out an accelerated data path to address the "kernel is too slow"
argument, I will choose the latter any day of the week.
Tom
>
> Because, we've seen time an time again that attempts to bypass the stack and
> run parallel stacks under the banner of "the kernel is too slow" does not
> scale for large deployment. We've seen this with RDMA, TOE, OpenOnload, and
> we'll see this for DPDK, FD.io, VPP and whatever else people are going to
> dream up. If I have a couple hundred machines running a single application
> like the HFT guys do, then sure I'd probably look into such solutions. But
> when I have datacenters with 100Ks running an assortment of applications
> even contemplating the possibility of deploying a parallel stacks gives me
> headache. We need to consider an seemingly endless list of security issues,
> manageability. robustness, protocol compatibility, etc. I really have little
> interest in bringing a huge pile of 3rd party code that I have to support,
> and I definitely have no interest in constantly replacing all of my hardware
> to get the latest and greatest support for these offloads as vendors leak
> them out. Given a choice between buying into some kernel bypass solution
> versus hacking Linux a little bit to carve out an accelerated data path to
> address the "kernel is too slow" argument, I will choose the latter any day
> of the week.
>
> Tom
>
>> XDP will always be less powerful and a lot more complicated,
>> especially considering users of dpdk (or toolkits built on top of it)
>> are not kernel programmers and userspace has more powerful ipc
>> (or storage) mechanisms.
>>
>> Aside from this, XDP, like DPDK, is a kernel bypass.
>> You might say 'Its just stack bypass, not a kernel bypass!'.
>> But what does that mean exactly? That packets can still be passed
>> onward to normal stack?
>> Bypass solutions like netmap can also inject packets back to
>> kernel stack again.
>>
>> Running less powerful user code in a restricted environment in the kernel
>> address space is certainly a worse idea than separating this logic out
>> to user space.
>>
>> In light of DPDKs existence it make a lot more sense to me to provide
>> a). a faster mmap based interface (possibly AF_PACKET based) that allows
>> to map nic directly into userspace, detaching tx/rx queue from kernel.
>>
>> John Fastabend sent something like this last year as a proof of
>> concept, iirc it was rejected because register space got exposed directly
>> to userspace. I think we should re-consider merging netmap
>> (or something conceptually close to its design).
>>
>> b). with regards to a programmable data path: IFF one wants to do this
>> in kernel (and thats a big if), it seems much more preferrable to provide
>> a config/data-based approach rather than a programmable one. If you want
>> full freedom DPDK is architecturally just too powerful to compete with.
>>
>> Proponents of XDP sometimes provide usage examples.
>> Lets look at some of these.
>>
>> == Application developement: ==
>> * DNS Server
>> data structures and algorithms need to be implemented in a mostly touring
>> complete language, so eBPF cannot readily be be used for that.
>> At least it will be orders of magnitude harder than in userspace.
>>
>> * TCP Endpoint
>> TCP processing in eBPF is a bit out of question while userspace tcp stacks
>> based on both netmap and dpdk already exist today.
>>
>> == Forwarding dataplane: ==
>>
>> * Router/Switch
>> Router and switches should actually adhere to standardized and specified
>> protocols and thus don't need a lot of custom software and specialized
>> software. Still a lot more work compared to userspace offloads where
>> you can do things like allocating a 4GB array to perform nexthop lookup.
>> Also needs ability to perform tx on another interface.
>>
>> * Load balancer
>> State holding algorithm need sorting and searching, so also no fit for
>> eBPF (could be exposed by function exports, but then can we do DoS by
>> finding worst case scenarios?).
>>
>> Also again needs way to forward frame out via another interface.
>>
>> For cases where packet gets sent out via same interface it would appear
>> to be easier to use port mirroring in a switch and use stochastic
>> filtering
>> on end nodes to determine which host should take responsibility.
>>
>> XDP plus: central authority over how distribution will work in case
>> nodes are added/removed from pool.
>> But then again, it will be easier to hande this with netmap/dpdk where
>> more complicated scheduling algorithms can be used.
>>
>> * early drop/filtering.
>> While its possible to do "u32" like filters with ebpf, all modern nics
>> support ntuple filtering in hardware, which is going to be faster because
>> such packet will never even be signalled to the operating system.
>> For more complicated cases (e.g. doing socket lookup to check if
>> particular
>> packet does match bound socket (and expected sequence numbers etc) I don't
>> see easy ways to do that with XDP (and without sk_buff context).
>> Providing it via function exports is possible of course, but that will
>> only
>> result in an "arms race" where we will see special-sauce functions
>> all over the place -- DoS will always attempt to go for something
>> that is difficult to filter against, cf. all the recent volume-based
>> floodings.
>>
>> Thanks, Florian
>
>
^ permalink raw reply
* Re: [PATCH 2/2] net: rfkill: Add rfkill-any LED trigger
From: kbuild test robot @ 2016-12-01 18:06 UTC (permalink / raw)
To: Michał Kępień
Cc: kbuild-all, Johannes Berg, David S . Miller, linux-wireless,
netdev, linux-kernel
In-Reply-To: <20161130120317.11851-2-kernel@kempniu.pl>
[-- Attachment #1: Type: text/plain, Size: 1459 bytes --]
Hi Michał,
[auto build test WARNING on mac80211-next/master]
[also build test WARNING on v4.9-rc7 next-20161201]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Micha-K-pie/net-rfkill-Cleanup-error-handling-in-rfkill_init/20161202-002119
base: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git master
config: blackfin-allmodconfig (attached as .config)
compiler: bfin-uclinux-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=blackfin
All warnings (new ones prefixed by >>):
>> WARNING: net/rfkill/rfkill.o(.init.text+0xa2): Section mismatch in reference from the function _init_module() to the function .exit.text:_rfkill_handler_exit()
The function __init _init_module() references
a function __exit _rfkill_handler_exit().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __exit annotation of
_rfkill_handler_exit() so it may be used outside an exit section.
---
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: 42125 bytes --]
^ permalink raw reply
* [PATCH iproute2 1/2] ss: print new tcp_info fields: delivery_rate and app_limited
From: Neal Cardwell @ 2016-12-01 18:21 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, Neal Cardwell, Yuchung Cheng, Eric Dumazet,
Soheil Hassas Yeganeh
Dump the new delivery_rate and delivery_rate_app_limited fields that
were added to tcp_info in Linux v4.9.
Example output:
pacing_rate 65.7Mbps delivery_rate 62.9Mbps
And for the application-limited case this looks like:
pacing_rate 1031.1Mbps delivery_rate 87.4Mbps app_limited
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
---
misc/ss.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/misc/ss.c b/misc/ss.c
index dd77b81..18cfa93 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -766,6 +766,7 @@ struct tcpstat {
unsigned int lastack;
double pacing_rate;
double pacing_rate_max;
+ double delivery_rate;
unsigned long long bytes_acked;
unsigned long long bytes_received;
unsigned int segs_out;
@@ -789,6 +790,7 @@ struct tcpstat {
bool has_ecnseen_opt;
bool has_fastopen_opt;
bool has_wscale_opt;
+ bool app_limited;
struct dctcpstat *dctcp;
struct tcp_bbr_info *bbr_info;
};
@@ -1868,6 +1870,11 @@ static void tcp_stats_print(struct tcpstat *s)
s->pacing_rate_max));
}
+ if (s->delivery_rate)
+ printf(" delivery_rate %sbps", sprint_bw(b1, s->delivery_rate));
+ if (s->app_limited)
+ printf(" app_limited");
+
if (s->unacked)
printf(" unacked:%u", s->unacked);
if (s->retrans || s->retrans_total)
@@ -2162,6 +2169,8 @@ static void tcp_show_info(const struct nlmsghdr *nlh, struct inet_diag_msg *r,
s.not_sent = info->tcpi_notsent_bytes;
if (info->tcpi_min_rtt && info->tcpi_min_rtt != ~0U)
s.min_rtt = (double) info->tcpi_min_rtt / 1000;
+ s.delivery_rate = info->tcpi_delivery_rate * 8.;
+ s.app_limited = info->tcpi_delivery_rate_app_limited;
tcp_stats_print(&s);
free(s.dctcp);
free(s.bbr_info);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH iproute2 2/2] ss: print new tcp_info fields: busy, rwnd-limited, sndbuf-limited times
From: Neal Cardwell @ 2016-12-01 18:21 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, Yuchung Cheng, Neal Cardwell, Eric Dumazet,
Soheil Hassas Yeganeh
In-Reply-To: <1480616500-16919-1-git-send-email-ncardwell@google.com>
From: Yuchung Cheng <ycheng@google.com>
Dump some new fields added to tcp_info in v4.10: tcpi_busy_time,
tcpi_rwnd_limited, tcpi_sndbuf_limited.
Example output for a flow busy for 110ms but never measurably limited by
receive window or send buffer:
busy:110ms
Example output for a flow usually limited by receive window:
busy:111ms rwnd_limited:101ms(91.0%)
Example output for a flow sometimes limited by send buffer:
busy:50ms sndbuf_limited:10ms(20.0%)
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
---
misc/ss.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/misc/ss.c b/misc/ss.c
index 18cfa93..392dbf7 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -784,6 +784,9 @@ struct tcpstat {
double rcv_rtt;
double min_rtt;
int rcv_space;
+ unsigned long long busy_time;
+ unsigned long long rwnd_limited;
+ unsigned long long sndbuf_limited;
bool has_ts_opt;
bool has_sack_opt;
bool has_ecn_opt;
@@ -1875,6 +1878,18 @@ static void tcp_stats_print(struct tcpstat *s)
if (s->app_limited)
printf(" app_limited");
+ if (s->busy_time) {
+ printf(" busy:%llums", s->busy_time / 1000);
+ if (s->rwnd_limited)
+ printf(" rwnd_limited:%llums(%.1f%%)",
+ s->rwnd_limited / 1000,
+ 100.0 * s->rwnd_limited / s->busy_time);
+ if (s->sndbuf_limited)
+ printf(" sndbuf_limited:%llums(%.1f%%)",
+ s->sndbuf_limited / 1000,
+ 100.0 * s->sndbuf_limited / s->busy_time);
+ }
+
if (s->unacked)
printf(" unacked:%u", s->unacked);
if (s->retrans || s->retrans_total)
@@ -2171,6 +2186,9 @@ static void tcp_show_info(const struct nlmsghdr *nlh, struct inet_diag_msg *r,
s.min_rtt = (double) info->tcpi_min_rtt / 1000;
s.delivery_rate = info->tcpi_delivery_rate * 8.;
s.app_limited = info->tcpi_delivery_rate_app_limited;
+ s.busy_time = info->tcpi_busy_time;
+ s.rwnd_limited = info->tcpi_rwnd_limited;
+ s.sndbuf_limited = info->tcpi_sndbuf_limited;
tcp_stats_print(&s);
free(s.dctcp);
free(s.bbr_info);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* RE: [PATCH v2] sh_eth: remove unchecked interrupts
From: Chris Brandt @ 2016-12-01 18:24 UTC (permalink / raw)
To: Sergei Shtylyov, David Miller
Cc: Simon Horman, Geert Uytterhoeven, netdev@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <7d50b5e0-ae7c-a39d-625a-c9cfc11e398f@cogentembedded.com>
On 12/1/2016, Sergei Shtylyov wrote:
> One thing you've missed so far is mentioning R7S72100 (RZ/A1) in the
> subject. This driver supports many SoCs, you're only fixing one of them...
For the last sh_eth.c patch I submitted, I had:
"net: ethernet: renesas: sh_eth: add POST registers for rz"
Should I resend the patch as:
"[PATCH v3] sh_eth: remove unchecked interrupts for RZ/A1"
??
Chris
^ permalink raw reply
* Re: [PATCH v2] sh_eth: remove unchecked interrupts
From: Sergei Shtylyov @ 2016-12-01 18:28 UTC (permalink / raw)
To: Chris Brandt, David Miller
Cc: Simon Horman, Geert Uytterhoeven, netdev@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <SG2PR06MB1165DFB4E735FC10696F08CA8A8F0@SG2PR06MB1165.apcprd06.prod.outlook.com>
On 12/01/2016 09:24 PM, Chris Brandt wrote:
>> One thing you've missed so far is mentioning R7S72100 (RZ/A1) in the
>> subject. This driver supports many SoCs, you're only fixing one of them...
>
> For the last sh_eth.c patch I submitted, I had:
>
> "net: ethernet: renesas: sh_eth: add POST registers for rz"
>
>
> Should I resend the patch as:
>
> "[PATCH v3] sh_eth: remove unchecked interrupts for RZ/A1"
>
>
> ??
Yes, that will do.
> Chris
MBR, Sergei
^ permalink raw reply
* [net PATCH 0/2] IPv4 FIB suffix length fixes
From: Alexander Duyck @ 2016-12-01 12:27 UTC (permalink / raw)
To: netdev, rshearma; +Cc: davem
In reviewing the patch from Robert Shearman and looking over the code I
realized there were a few different bugs we were still carrying in the IPv4
FIB lookup code.
These two patches are based off of Robert's original patch, but take things
one step further by splitting them up to address two additional issues I
found.
So first have Robert's original patch which was addressing the fact that
us calling update_suffix in resize is expensive when it is called per add.
To address that I incorporated the core bit of the patch which was us
dropping the update_suffix call from resize.
The first patch in the series does a rename and fix on the push_suffix and
pull_suffix code. Specifically we drop the need to pass a leaf and
secondly we fix things so we pull the suffix as long as the value of the
suffix in the node is dropping.
The second patch addresses the original issue reported as well as
optimizing the code for the fact that update_suffix is only really meant to
go through and clean things up when we are decreasing a suffix. I had
originally added code for it to somehow cause an increase, but if we push
the suffix when a new leaf is added we only ever have to handle pulling
down the suffix with update_suffix so I updated the code to reflect that.
As far as side effects the only ones I think that will be obvious should be
the fact that some routes may be able to be found earlier since before we
relied on resize to update the suffix lengths, and now we are updating them
before we add or remove the leaf.
---
Alexander Duyck (2):
ipv4: Drop leaf from suffix pull/push functions
ipv4: Drop suffix update from resize code
net/ipv4/fib_trie.c | 68 ++++++++++++++++++++++++++-------------------------
1 file changed, 35 insertions(+), 33 deletions(-)
^ permalink raw reply
* [net PATCH 1/2] ipv4: Drop leaf from suffix pull/push functions
From: Alexander Duyck @ 2016-12-01 12:27 UTC (permalink / raw)
To: netdev, rshearma; +Cc: davem
In-Reply-To: <20161201121605.15499.13176.stgit@ahduyck-blue-test.jf.intel.com>
It wasn't necessary to pass a leaf in when doing the suffix updates so just
drop it. Instead just pass the suffix and work with that.
Since we dropped the leaf there is no need to include that in the name so
the names are updated to node_push_suffix and node_pull_suffix.
Finally I noticed that the logic for pulling the suffix length back
actually had some issues. Specifically it would stop prematurely if there
was a longer suffix, but it was not as long as the original suffix. I
updated the code to address that in node_pull_suffix.
Fixes: 5405afd1a306 ("fib_trie: Add tracking value for suffix length")
Suggested-by: Robert Shearman <rshearma@brocade.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
net/ipv4/fib_trie.c | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index e2ffc2a..c5cd226 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -892,22 +892,24 @@ static struct key_vector *resize(struct trie *t, struct key_vector *tn)
return tp;
}
-static void leaf_pull_suffix(struct key_vector *tp, struct key_vector *l)
+static void node_pull_suffix(struct key_vector *tn, unsigned char slen)
{
- while ((tp->slen > tp->pos) && (tp->slen > l->slen)) {
- if (update_suffix(tp) > l->slen)
+ unsigned char node_slen = tn->slen;
+
+ while ((node_slen > tn->pos) && (node_slen > slen)) {
+ slen = update_suffix(tn);
+ if (node_slen == slen)
break;
- tp = node_parent(tp);
+
+ tn = node_parent(tn);
+ node_slen = tn->slen;
}
}
-static void leaf_push_suffix(struct key_vector *tn, struct key_vector *l)
+static void node_push_suffix(struct key_vector *tn, unsigned char slen)
{
- /* if this is a new leaf then tn will be NULL and we can sort
- * out parent suffix lengths as a part of trie_rebalance
- */
- while (tn->slen < l->slen) {
- tn->slen = l->slen;
+ while (tn->slen < slen) {
+ tn->slen = slen;
tn = node_parent(tn);
}
}
@@ -1069,7 +1071,7 @@ static int fib_insert_alias(struct trie *t, struct key_vector *tp,
/* if we added to the tail node then we need to update slen */
if (l->slen < new->fa_slen) {
l->slen = new->fa_slen;
- leaf_push_suffix(tp, l);
+ node_push_suffix(tp, new->fa_slen);
}
return 0;
@@ -1482,7 +1484,7 @@ static void fib_remove_alias(struct trie *t, struct key_vector *tp,
/* update the trie with the latest suffix length */
l->slen = fa->fa_slen;
- leaf_pull_suffix(tp, l);
+ node_pull_suffix(tp, fa->fa_slen);
}
/* Caller must hold RTNL. */
^ permalink raw reply related
* Re: [PATCH net] fib_trie: Avoid expensive update of suffix length when not required
From: Alexander Duyck @ 2016-12-01 18:29 UTC (permalink / raw)
To: Robert Shearman; +Cc: David Miller, Netdev, Alexander Duyck
In-Reply-To: <50c4f236-c486-1224-e3b0-c3e322d68d58@brocade.com>
On Wed, Nov 30, 2016 at 4:27 PM, Robert Shearman <rshearma@brocade.com> wrote:
> On 29/11/16 23:14, Alexander Duyck wrote:
>>
>> On Tue, Nov 29, 2016 at 9:46 AM, Robert Shearman <rshearma@brocade.com>
>> wrote:
>>>
>>> With certain distributions of routes it can take a long time to add
>>> and delete further routes at scale. For example, with a route for
>>> 10.37.96.0/20 present it takes 47s to add ~200k contiguous /24 routes
>>> from 8.0.0.0/24 through to 11.138.207.0/24. Perf shows the bottleneck
>>> is update_suffix:
>>>
>>> 40.39% [kernel] [k] update_suffix
>>> 8.02% libnl-3.so.200.19.0 [.] nl_hash_table_lookup
>>
>>
>> Well yeah, it will be expensive when you have over 512K entries in a
>> single node. I'm assuming that is the case based on the fact that
>> 200K routes will double up in the trie node due to broadcast and the
>> route ending up in adjacent key vectors.
>
>
> The example scenario was in fact using a large scale of just routes rather
> than addresses so there are no broadcast leafs (nor local leafs):
>
> +-- 8.0.0.0/6 18 2 52436 suffix/20
> |-- 8.0.0.0
> /24 universe UNICAST
> |-- 8.0.1.0
> /24 universe UNICAST
> |-- 8.0.2.0
> /24 universe UNICAST
>
> (the "suffix/20" is for test purposes as per below). In this case the
> 8.0.0.0/6 node has a child array of size 2^18 = 262144.
>
>>
>>> With these changes, the time is reduced to 4s for the same scale and
>>> distribution of routes.
>>>
>>> The issue is that update_suffix does an O(n) walk on the children of a
>>> node and the with a dense distribtion of routes the number of children
>>> in a node tends towards the number of nodes in the tree.
>>
>>
>> Other than the performance I was just wondering if you did any other
>> validation to confirm that nothing else differs. Basically it would
>> just be a matter of verifying that /proc/net/fib_trie is the same
>> before and after your patch.
>
>
> Yes, to verify these changes I applied some local changes to dump the slen
> field of trie nodes from /proc/net/fib_trie. I presumed that the format of
> /proc/net/fib_trie is a public API that we can't break so I intend to submit
> this as a patch. I verified by inspection that the suffix length listed in
> the nodes was as expected when exercising the insert and remove functions
> for routes with both larger and smaller suffixes than in the current nodes,
> and then for the inflate, halve and flush cases.
>
> I've now verified that a diff of /proc/net/fib_trie before and after my
> patch with all the routes added of my example scenario shows no changes.
>
>>
> ...
>>>
>>> Fixes: 5405afd1a306 ("fib_trie: Add tracking value for suffix length")
>>> Signed-off-by: Robert Shearman <rshearma@brocade.com>
>>
>>
>> So I am not entirely convinced this is a regression, I was wondering
>> what your numbers looked like before the patch you are saying this
>> fixes? I recall I fixed a number of issues leading up to this so I am
>> just curious.
>
>
> At commit 21d1f11db0e2f20a549ad8322879507850544670 ("fib_trie: Remove checks
> for index >= tnode_child_length from tnode_get_child") which is the parent
> of 5405afd1a306:
>
> $ time sudo ip route restore < ~/allroutes
> RTNETLINK answers: File exists
> RTNETLINK answers: File exists
> RTNETLINK answers: File exists
> RTNETLINK answers: File exists
>
> real 0m3.451s
> user 0m0.184s
> sys 0m2.004s
>
>
> At commit 5405afd1a30620de8601436bae739c67c0bc7324 ("fib_trie: Add tracking
> value for suffix length"):
>
> $ time sudo ip route restore < ~/allroutes
> RTNETLINK answers: File exists
> RTNETLINK answers: File exists
> RTNETLINK answers: File exists
> RTNETLINK answers: File exists
>
> real 0m48.624s
> user 0m0.360s
> sys 0m46.960s
>
> So does that warrant a fixes tag for this patch?
Yes, please include it in the patch description next time.
I've been giving it thought and the fact is the patch series has
merit. I just think it was being a bit too aggressive in terms of
some of the changes. So placing any changes in put_child seem to be
the one piece in this that make this a bit ugly. I'll submit a
counter proposal, if you could try testing it I would appreciate it,
or if you could look at incorporating some of it into your patch it
would be useful.
>>
>> My thought is this seems more like a performance optimization than a
>> fix. If that is the case this probably belongs in net-next.
>>
>> It seems to me we might be able to simplify update_suffix rather than
>> going through all this change. That might be something that is more
>> acceptable for net. Have you looked at simply adding code so that
>> there is a break inside update_suffix if (slen == tn->slen)? We don't
>> have to call it for if a leaf is added so it might make sense to add
>> that check.
>
>
> That doesn't really help since the search always starts from the smallest
> suffix length and thus could potentially require visiting a large number of
> children before finding the node that makes slen == tn->slen.
>
> In the example above, 10.37.96.0/20 would be child number 140640 in node
> 8.0.0.0/6 18. Since the loop starts out with stride = 2 this means that it
> requires 70320 iterations round to find 10.37.96.0/20 which contributes the
> largest suffix length to the node.
Yes, however that is still 60K fewer iterations we would have to do.
> Now it may be possible to improve the algorithm by starting the search from
> the largest suffix length towards the smallest suffix length instead of the
> current smallest to largest, but there would still be distributions of
> routes that would lead to needing to visit a large number of nodes only to
> find that nothing has changed.
The largest possible suffix always starts at 0. Any bits in the index
mean that the suffix has to stop before that bit since suffix
represents the number of bits that are 0. By starting at 0 and
increasing the stride as we hit bigger values we should be about as
optimal there as we can be.
>>
>>> ---
>>> net/ipv4/fib_trie.c | 86
>>> ++++++++++++++++++++++++++++++++++++++---------------
>>> 1 file changed, 62 insertions(+), 24 deletions(-)
>>>
>>> diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
>>> index 026f309c51e9..701cae8af44a 100644
>>> --- a/net/ipv4/fib_trie.c
>>> +++ b/net/ipv4/fib_trie.c
>>> @@ -421,8 +421,22 @@ static inline int tnode_full(struct key_vector *tn,
>>> struct key_vector *n)
>>> return n && ((n->pos + n->bits) == tn->pos) && IS_TNODE(n);
>>> }
>>>
>>> +static void node_push_suffix(struct key_vector *tn, struct key_vector
>>> *l)
>>> +{
>>> + while (tn->slen < l->slen) {
>>> + tn->slen = l->slen;
>>> + tn = node_parent(tn);
>>> + if (!tn)
>>> + break;
>>
>>
>> I don't think the NULL check is necessary, at least it wasn't with the old
>> code.
>
>
> It wasn't necessary before because the root node had the largest possible
> suffix length of KEYLENGTH. This isn't the case for the nodes this is now
> called on since they're either nodes without parents or sub-tries that end
> up in node without a parent, where they're initialised to have the smallest
> possible suffix length for the node (equal to their position).
>
>>
>>> + }
>>> +}
>>> +
>>> /* Add a child at position i overwriting the old value.
>>> * Update the value of full_children and empty_children.
>>> + *
>>> + * The suffix length of the parent node and the rest of the tree is
>>> + * updated (if required) when adding/replacing a node, but is caller's
>>> + * responsibility on removal.
>>> */
>>> static void put_child(struct key_vector *tn, unsigned long i,
>>> struct key_vector *n)
>>> @@ -447,8 +461,8 @@ static void put_child(struct key_vector *tn, unsigned
>>> long i,
>>> else if (!wasfull && isfull)
>>> tn_info(tn)->full_children++;
>>>
>>> - if (n && (tn->slen < n->slen))
>>> - tn->slen = n->slen;
>>> + if (n)
>>> + node_push_suffix(tn, n);
>>
>>
>> This is just creating redundant work if we have to perform a resize.
>
>
> The only real redundant work is the assignment of slen in tn, since the
> propagation up the trie has to happen regardless and if a subsequent resize
> results in changes to the trie then the propagation will stop at tn's parent
> since the suffix length of the tn's parent will not be less than tn's suffix
> length.
This isn't going to work. We want to avoid trying to push the suffix
when we place a child. There are scenarios where we are placing
children in nodes that don't have parents yet because we are doing
rebalances and such. I suspect this could be pretty expensive on a
resize call.
We want to pull the suffix pushing out of the resize completely. The
problem is this is going to cause us to start pushing suffixes for
every node moved as a part of resize.
>>
>>> rcu_assign_pointer(tn->tnode[i], n);
>>> }
>
> ...
>
>>> -static void leaf_pull_suffix(struct key_vector *tp, struct key_vector
>>> *l)
>>> +static void node_set_suffix(struct key_vector *tp, unsigned char slen)
>>> {
>>> - while ((tp->slen > tp->pos) && (tp->slen > l->slen)) {
>>> - if (update_suffix(tp) > l->slen)
>>> + if (slen > tp->slen)
>>> + tp->slen = slen;
>>> +}
>>> +
>>> +static void node_pull_suffix(struct key_vector *tn)
>>> +{
>>> + struct key_vector *tp;
>>> + unsigned char slen;
>>> +
>>> + slen = update_suffix(tn);
>>> + tp = node_parent(tn);
>>> + while ((tp->slen > tp->pos) && (tp->slen > slen)) {
>>> + if (update_suffix(tp) > slen)
>>> break;
>>> tp = node_parent(tp);
>>> }
>>> }
>>>
>>
Actually I realized that there is a bug here. The check for
update_suffix(tp) > slen can cause us to stop prematurely if I am not
mistaken. What we should probably be doing is pulling out tp->slen
and if the result of update_suffix is the same value then we can break
the loop. Otherwise we can stop early if a "second runner up" shows
up that is supposed to be pushed up the trie.
I actually started around with patches to do much the same as what you
are doing and I will probably submit them as an RFC so if you need you
can pick pieces out as needed, or I could submit them if they work for
you.
>> I really hate all the renaming. Can't you just leave these as
>> leaf_pull_suffix and leaf_push _suffix. I'm fine with us dropping the
>> leaf of the suffix but the renaming just makes adds a bunch of noise.
>> Really it might work better if you broke the replacement of the
>> key_vector as a leaf with the suffix length into a separate patch,
>> then you could do the rename as a part of that.
>
>
> Ok, I'll leave the naming of leaf_push_suffix alone. Note that
> leaf_pull_suffix hasn't been renamed, the below in the diff is just an
> artifact of how diff decided to present the changes along with the moving of
> leaf_push_suffix.
So I have been looking this over for the last couple days and actually
I have started to be okay with the renaming.
However I would ask to be consistent. If you are going to have
node_pull_suffix and node_push_suffix then just pass a node and a
suffix length. You can drop the leaf key vector from both functions
instead of just one.
>>
>>> -static void leaf_push_suffix(struct key_vector *tn, struct key_vector
>>> *l)
>>> +static void leaf_pull_suffix(struct key_vector *tp, struct key_vector
>>> *l)
>>> {
>>> - /* if this is a new leaf then tn will be NULL and we can sort
>>> - * out parent suffix lengths as a part of trie_rebalance
>>> - */
>>> - while (tn->slen < l->slen) {
>>> - tn->slen = l->slen;
>>> - tn = node_parent(tn);
>>> + while ((tp->slen > tp->pos) && (tp->slen > l->slen)) {
>>> + if (update_suffix(tp) > l->slen)
>>> + break;
>>> + tp = node_parent(tp);
>>> }
>>> }
>>
>>
>> If possible it would work better if you could avoid moving functions
>> around as a result of your changes.
>
>
> Ok, I can add a forward declaration instead.
It shouldn't be necessary. I think you are doing way too much with
this patch. We just need this to be a fix, you are doing a bit too
much like adding this new node_set_suffix function which isn't really
needed.
>>
>>> @@ -1107,7 +1122,7 @@ static int fib_insert_alias(struct trie *t, struct
>>> key_vector *tp,
>>> /* if we added to the tail node then we need to update slen */
>>> if (l->slen < new->fa_slen) {
>>> l->slen = new->fa_slen;
>>> - leaf_push_suffix(tp, l);
>>> + node_push_suffix(tp, l);
>>> }
>>>
>>> return 0;
>
> ...
>>>
>>> @@ -1783,6 +1801,16 @@ void fib_table_flush_external(struct fib_table
>>> *tb)
>>> if (IS_TRIE(pn))
>>> break;
>>>
>>> + /* push the suffix length to the parent node,
>>> + * since a previous leaf removal may have
>>> + * caused it to change
>>> + */
>>> + if (pn->slen > pn->pos) {
>>> + unsigned char slen = update_suffix(pn);
>>> +
>>> + node_set_suffix(node_parent(pn), slen);
>>> + }
>>> +
>>
>>
>> Why bother with the local variable? You could just pass
>> update_suffix(pn) as the parameter to your node_set_suffix function.
>
>
> To avoid a long line on the node_set_suffix call or splitting it across
> lines, but I'll remove the local variable as you suggest and the same below.
Actually I think there is a bug here. You shouldn't be setting the
suffix for the parent based on the child. You can just call
update_suffix(pn) and that should be enough.
^ permalink raw reply
* [net PATCH 2/2] ipv4: Drop suffix update from resize code
From: Alexander Duyck @ 2016-12-01 12:27 UTC (permalink / raw)
To: netdev, rshearma; +Cc: davem
In-Reply-To: <20161201121605.15499.13176.stgit@ahduyck-blue-test.jf.intel.com>
It has been reported that update_suffix can be expensive when it is called
on a large node in which most of the suffix lengths are the same. The time
required to add 200K entries had increased from around 3 seconds to almost
49 seconds.
In order to address this we need to move the code for updating the suffix
out of resize and instead just have it handled in the cases where we are
pushing a node that increases the suffix length, or will decrease the
suffix length.
Fixes: 5405afd1a306 ("fib_trie: Add tracking value for suffix length")
Reported-by: Robert Shearman <rshearma@brocade.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
net/ipv4/fib_trie.c | 42 +++++++++++++++++++++---------------------
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index c5cd226..2cfa9f4 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -681,6 +681,13 @@ static unsigned char update_suffix(struct key_vector *tn)
{
unsigned char slen = tn->pos;
unsigned long stride, i;
+ unsigned char slen_max;
+
+ /* only vector 0 can have a suffix length greater than or equal to
+ * tn->pos + tn->bits, the second highest node will have a suffix
+ * length at most of tn->pos + tn->bits - 1
+ */
+ slen_max = min_t(unsigned char, tn->pos + tn->bits - 1, tn->slen);
/* search though the list of children looking for nodes that might
* have a suffix greater than the one we currently have. This is
@@ -698,12 +705,8 @@ static unsigned char update_suffix(struct key_vector *tn)
slen = n->slen;
i &= ~(stride - 1);
- /* if slen covers all but the last bit we can stop here
- * there will be nothing longer than that since only node
- * 0 and 1 << (bits - 1) could have that as their suffix
- * length.
- */
- if ((slen + 1) >= (tn->pos + tn->bits))
+ /* stop searching if we have hit the maximum possible value */
+ if (slen >= slen_max)
break;
}
@@ -875,21 +878,7 @@ static struct key_vector *resize(struct trie *t, struct key_vector *tn)
return collapse(t, tn);
/* update parent in case halve failed */
- tp = node_parent(tn);
-
- /* Return if at least one deflate was run */
- if (max_work != MAX_WORK)
- return tp;
-
- /* push the suffix length to the parent node */
- if (tn->slen > tn->pos) {
- unsigned char slen = update_suffix(tn);
-
- if (slen > tp->slen)
- tp->slen = slen;
- }
-
- return tp;
+ return node_parent(tn);
}
static void node_pull_suffix(struct key_vector *tn, unsigned char slen)
@@ -1030,6 +1019,7 @@ static int fib_insert_node(struct trie *t, struct key_vector *tp,
}
/* Case 3: n is NULL, and will just insert a new leaf */
+ node_push_suffix(tp, new->fa_slen);
NODE_INIT_PARENT(l, tp);
put_child_root(tp, key, l);
trie_rebalance(t, tp);
@@ -1472,6 +1462,8 @@ static void fib_remove_alias(struct trie *t, struct key_vector *tp,
* out parent suffix lengths as a part of trie_rebalance
*/
if (hlist_empty(&l->leaf)) {
+ if (tp->slen == l->slen)
+ node_pull_suffix(tp, tp->pos);
put_child_root(tp, l->key, NULL);
node_free(l);
trie_rebalance(t, tp);
@@ -1753,6 +1745,10 @@ void fib_table_flush_external(struct fib_table *tb)
if (IS_TRIE(pn))
break;
+ /* update the suffix to address pulled leaves */
+ if (pn->slen > pn->pos)
+ update_suffix(pn);
+
/* resize completed node */
pn = resize(t, pn);
cindex = get_index(pkey, pn);
@@ -1828,6 +1824,10 @@ int fib_table_flush(struct fib_table *tb)
if (IS_TRIE(pn))
break;
+ /* update the suffix to address pulled leaves */
+ if (pn->slen > pn->pos)
+ update_suffix(pn);
+
/* resize completed node */
pn = resize(t, pn);
cindex = get_index(pkey, pn);
^ permalink raw reply related
* [PATCH v3] sh_eth: remove unchecked interrupts for RZ/A1
From: Chris Brandt @ 2016-12-01 18:32 UTC (permalink / raw)
To: David Miller, Sergei Shtylyov
Cc: Simon Horman, Geert Uytterhoeven, netdev, linux-renesas-soc,
Chris Brandt
When streaming a lot of data and the RZ/A1 can't keep up, some status bits
will get set that are not being checked or cleared which cause the
following messages and the Ethernet driver to stop working. This
patch fixes that issue.
irq 21: nobody cared (try booting with the "irqpoll" option)
handlers:
[<c036b71c>] sh_eth_interrupt
Disabling IRQ #21
Fixes: db893473d313a4ad ("sh_eth: Add support for r7s72100")
Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
v3:
* add RZ/A1 to subject line
v2:
* switched from modifying eesr_err_check to modifying eesipr_value
---
drivers/net/ethernet/renesas/sh_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
index 05b0dc5..1a92de7 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -518,7 +518,7 @@ static struct sh_eth_cpu_data r7s72100_data = {
.ecsr_value = ECSR_ICD,
.ecsipr_value = ECSIPR_ICDIP,
- .eesipr_value = 0xff7f009f,
+ .eesipr_value = 0xe77f009f,
.tx_check = EESR_TC1 | EESR_FTC,
.eesr_err_check = EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT |
--
2.10.1
^ permalink raw reply related
* pull-request: wireless-drivers-next 2016-12-01
From: Kalle Valo @ 2016-12-01 18:33 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's another pull request for net-next. Nothing special to mention
about, the details are in the signed tag below.
This time there's a trivial conflict in
drivers/net/wireless/ath/ath10k/mac.c:
<<<<<<< HEAD
ieee80211_hw_set(ar->hw, SUPPORTS_TX_FRAG);
=======
ieee80211_hw_set(ar->hw, REPORTS_LOW_ACK);
>>>>>>> d5fb3a138048798ce4cc4b4ced47d07d1794c577
We want to have both flags enabled in ath10k.
I'm planning to submit at least one more pull request, if Linus gives us
one more week I might send even two. For example there are patches to
convert wcn36xx to use the real SMD bus subsystem but they depend on few
arm-soc patches. I'll send a separate email about that, they are not
part of this pull request.
Please let me know if there are any problems.
Kalle
The following changes since commit 159a55a64d44acbbd6f0d8f3c082e628d6d75670:
rt2800: disable CCK rates on HT (2016-11-23 17:38:53 +0200)
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-2016-12-01
for you to fetch changes up to d5fb3a138048798ce4cc4b4ced47d07d1794c577:
Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2016-12-01 15:09:14 +0200)
----------------------------------------------------------------
wireless-drivers-next patches for 4.10
Major changes:
rsi
* filter rx frames
* configure tx power
* make it possible to select antenna
* support 802.11d
brcmfmac
* cleanup of scheduled scan code
* support for bcm43341 chipset with different chip id
* support rev6 of PCIe device interface
ath10k
* add spectral scan support for QCA6174 and QCA9377 families
* show used tx bitrate with 10.4 firmware
wil6210
* add power save mode support
* add abort scan functionality
* add support settings retry limit for short frames
bcma
* add Dell Inspiron 3148
----------------------------------------------------------------
Anilkumar Kolli (2):
ath10k: add per peer htt tx stats support for 10.4
ath10k: add support for per sta tx bitrate
Anthony Romano (2):
mt7601u: wait for clear rxq when stopping mac
ath9k_htc: don't use HZ for usb msg timeouts
Arend Van Spriel (11):
brcmfmac: add support for 43341 chip
brcmfmac: move pno helper functions in separate source file
brcmfmac: fix handling ssids in .sched_scan_start() callback
brcmfmac: change prototype for brcmf_do_escan()
brcmfmac: make internal escan more generic
brcmfmac: split up brcmf_pno_config() function
brcmfmac: move scheduled scan activation to pno source file
brcmfmac: use provided channels for scheduled scan
brcmfmac: remove restriction from .sched_scan_start() callback
brcmfmac: use requested scan interval in scheduled scan
brcmfmac: fix scheduled scan result handling for newer chips
Barry Day (1):
rtl8xxxu: tx rate reported before set
Ben Greear (1):
ath10k: wmi-alloc-chunk should use DMA_BIDIRECTIONAL
Bhumika Goyal (1):
ath9k: constify ath_bus_ops structure
Brian Norris (3):
mwifiex: cleanup wake-IRQ handling if suspend fails
mwifiex: avoid double-disable_irq() race
mwifiex: pcie: implement timeout loop for FW programming doorbell
Dedy Lansky (1):
wil6210: fix net queue stop/wake
Erik Stromdahl (1):
ath10k: fix TLV set regdomain command
Franky Lin (1):
brcmfmac: add pcie host dongle interface rev6 support
Geliang Tang (1):
ath5k: drop duplicate header vmalloc.h
Jes Sorensen (7):
rtl8xxxu: Fix memory leak in handling rxdesc16 packets
rtl8xxxu: Fix big-endian problem reporting mactime
rtl8xxxu: Fix rtl8723bu driver reload issue
rtl8xxxu: Fix rtl8192eu driver reload issue
rtl8xxxu: Obtain RTS rates from mac80211
rtl8xxxu: Pass tx_info to fill_txdesc in order to have access to retry count
rtl8xxxu: Work around issue with 8192eu and 8723bu devices not reconnecting
Jiri Slaby (1):
bcma: add Dell Inspiron 3148
Kalle Valo (1):
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Karthik D A (1):
mwifiex: Disable adhoc feature based on firmware capability
Kirtika Ruchandani (7):
mwifiex: Removed unused mwifiex_private* 'priv' variable
mwifiex: Remove unused 'chan_num' variable
mwifiex: Remove unused 'sta_ptr' variable
mwifiex: Remove unused 'adapter'variable
mwifiex: Remove unused 'pm_flag' variable
mwifiex: Removed unused 'pkt_type' variable
mwifiex: Remove unused 'bcd_usb' variable
Larry Finger (1):
rtlwifi: Fix enter/exit power_save
Lior David (6):
wil6210: fix deadlock when using fw_no_recovery option
wil6210: align to latest auto generated wmi.h
wil6210: support NL80211_ATTR_WIPHY_RETRY_SHORT
wil6210: delay remain on channel when scan is active
wil6210: add debugfs blobs for UCODE code and data
wil6210: align to latest auto generated wmi.h
Manoharan, Rajkumar (1):
ath10k: fix monitor vdev for receiving other bss frames
Matthias Schiffer (1):
ath9k: fix ath9k_hw_gpio_get() to return 0 or 1 on success
Maya Erez (3):
wil6210: add support for power save enable / disable
wil6210: add support for abort scan
wil6210: validate wil_pmc_alloc parameters
Miaoqing Pan (1):
ath9k: fix NULL pointer dereference
Michal Kazior (2):
ath10k: fix null deref on wmi-tlv when trying spectral scan
ath10k: add spectral scan support to wmi-tlv
Mohammed Shafi Shajakhan (2):
ath10k: fix soft lockup during firmware crash/hw-restart
ath10k: fix Tx DMA alloc failure during continuous wifi down/up
Pedersen, Thomas (2):
ath10k: implement offset_tsf ieee80211_op
ath10k: remove set/get_tsf ieee80211_ops
Prameela Rani Garnepudi (4):
rsi: Add support to filter rx frames
rsi: Add support for configuring tx power
rsi: Add support for antenna selection
rsi: Add support for 802.11d
Rajkumar Manoharan (1):
ath10k: advertize hardware packet loss mechanism
Tobias Regnery (1):
brcmsmac: fix array out-of-bounds access in qm_log10
Wei Yongjun (1):
rtl8xxxu: Fix non static symbol warning
Zefir Kurtisi (1):
ath9k: feed only active spectral / dfs-detector
drivers/bcma/host_pci.c | 1 +
drivers/net/wireless/ath/ath10k/core.c | 8 +-
drivers/net/wireless/ath/ath10k/core.h | 24 +
drivers/net/wireless/ath/ath10k/debugfs_sta.c | 13 +
drivers/net/wireless/ath/ath10k/htt.c | 2 +
drivers/net/wireless/ath/ath10k/htt.h | 31 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 125 +++++
drivers/net/wireless/ath/ath10k/htt_tx.c | 54 +-
drivers/net/wireless/ath/ath10k/mac.c | 51 +-
drivers/net/wireless/ath/ath10k/wmi-ops.h | 6 +
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 77 ++-
drivers/net/wireless/ath/ath10k/wmi.c | 8 +-
drivers/net/wireless/ath/ath10k/wmi.h | 18 +-
drivers/net/wireless/ath/ath5k/debug.c | 1 -
drivers/net/wireless/ath/ath9k/ahb.c | 2 +-
drivers/net/wireless/ath/ath9k/common-spectral.c | 8 +-
drivers/net/wireless/ath/ath9k/hif_usb.c | 9 +-
drivers/net/wireless/ath/ath9k/hif_usb.h | 2 +
drivers/net/wireless/ath/ath9k/hw.c | 2 +-
drivers/net/wireless/ath/ath9k/recv.c | 17 +-
drivers/net/wireless/ath/wil6210/cfg80211.c | 129 ++++-
drivers/net/wireless/ath/wil6210/main.c | 100 ++--
drivers/net/wireless/ath/wil6210/netdev.c | 2 +-
drivers/net/wireless/ath/wil6210/p2p.c | 160 ++++--
drivers/net/wireless/ath/wil6210/pmc.c | 55 +-
drivers/net/wireless/ath/wil6210/txrx.c | 110 +++-
drivers/net/wireless/ath/wil6210/wil6210.h | 25 +-
drivers/net/wireless/ath/wil6210/wil_crash_dump.c | 6 +
drivers/net/wireless/ath/wil6210/wmi.c | 160 +++++-
drivers/net/wireless/ath/wil6210/wmi.h | 586 ++++++++++++++++----
.../wireless/broadcom/brcm80211/brcmfmac/Makefile | 3 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/bus.h | 10 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 381 +++++--------
.../broadcom/brcm80211/brcmfmac/cfg80211.h | 4 +-
.../broadcom/brcm80211/brcmfmac/fwil_types.h | 23 +
.../wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 38 +-
.../wireless/broadcom/brcm80211/brcmfmac/msgbuf.h | 4 +
.../wireless/broadcom/brcm80211/brcmfmac/pcie.c | 171 +++---
.../net/wireless/broadcom/brcm80211/brcmfmac/pno.c | 242 ++++++++
.../net/wireless/broadcom/brcm80211/brcmfmac/pno.h | 40 ++
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 1 +
.../broadcom/brcm80211/brcmsmac/phy/phy_qmath.c | 5 +-
.../broadcom/brcm80211/include/brcm_hw_ids.h | 1 +
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 12 +-
drivers/net/wireless/marvell/mwifiex/fw.h | 1 +
drivers/net/wireless/marvell/mwifiex/main.c | 3 -
drivers/net/wireless/marvell/mwifiex/main.h | 9 +-
drivers/net/wireless/marvell/mwifiex/pcie.c | 17 +-
drivers/net/wireless/marvell/mwifiex/scan.c | 8 +-
drivers/net/wireless/marvell/mwifiex/sdio.c | 6 +-
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 38 +-
drivers/net/wireless/marvell/mwifiex/usb.c | 3 +-
drivers/net/wireless/mediatek/mt7601u/init.c | 14 +-
drivers/net/wireless/mediatek/mt7601u/regs.h | 3 +
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 31 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 10 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 4 +
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 122 ++--
drivers/net/wireless/realtek/rtlwifi/base.c | 8 +-
drivers/net/wireless/realtek/rtlwifi/core.c | 9 +-
drivers/net/wireless/realtek/rtlwifi/pci.c | 14 +-
drivers/net/wireless/realtek/rtlwifi/ps.c | 36 +-
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 156 +++++-
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 129 ++++-
drivers/net/wireless/rsi/rsi_main.h | 4 +
drivers/net/wireless/rsi/rsi_mgmt.h | 23 +-
66 files changed, 2581 insertions(+), 794 deletions(-)
create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c
create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.h
^ permalink raw reply
* Re: linux-next: Tree for Dec 1 (ethernet/mellanox)
From: Randy Dunlap @ 2016-12-01 18:38 UTC (permalink / raw)
To: Stephen Rothwell, linux-next
Cc: linux-kernel, netdev@vger.kernel.org, Tariq Toukan,
Saeed Mahameed
In-Reply-To: <20161201174235.21689436@canb.auug.org.au>
On 11/30/16 22:42, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20161130:
>
on i386:
when CONFIG_INET is not enabled:
drivers/built-in.o: In function `mlx5e_test_loopback':
en_selftest.c:(.text+0x690bde): undefined reference to `ip_send_check'
en_selftest.c:(.text+0x690c42): undefined reference to `udp4_hwcsum'
--
~Randy
^ permalink raw reply
* Re: [iproute PATCH 04/18] ss: Use sockstat->type in all socket types
From: Stephen Hemminger @ 2016-12-01 18:41 UTC (permalink / raw)
To: Phil Sutter; +Cc: netdev
In-Reply-To: <20161111131014.21865-5-phil@nwl.cc>
On Fri, 11 Nov 2016 14:10:00 +0100
Phil Sutter <phil@nwl.cc> wrote:
> Unix sockets used that field already to hold info about the socket type.
> By replicating this approach in all other socket types, we can get rid
> of protocol parameter in inet_stats_print() and have sock_state_print()
> figure things out by itself.
>
> Signed-off-by: Phil Sutter <phil@nwl.cc>
Cleaning out the patch backlog...
This patch does not apply to current master branch, rejects are:
--- misc/ss.c
+++ misc/ss.c
@@ -1719,27 +1768,11 @@ void *parse_markmask(const char *markmask)
return res;
}
-static char *proto_name(int protocol)
-{
- switch (protocol) {
- case 0:
- return "raw";
- case IPPROTO_UDP:
- return "udp";
- case IPPROTO_TCP:
- return "tcp";
- case IPPROTO_DCCP:
- return "dccp";
- }
-
- return "???";
-}
-
-static void inet_stats_print(struct sockstat *s, int protocol)
+static void inet_stats_print(struct sockstat *s)
{
char *buf = NULL;
- sock_state_print(s, proto_name(protocol));
+ sock_state_print(s);
inet_addr_print(&s->local, s->lport, s->iface);
inet_addr_print(&s->remote, s->rport, 0);
Please fix and resubmit whole series.
^ permalink raw reply
* Re: [PATCH iproute2 2/3] ifstat: Add extended statistics to ifstat
From: Stephen Hemminger @ 2016-12-01 18:46 UTC (permalink / raw)
To: Nogah Frankel; +Cc: netdev, eladr, yotamg, jiri, idosch, ogerlitz
In-Reply-To: <1479996760-61271-3-git-send-email-nogahf@mellanox.com>
On Thu, 24 Nov 2016 16:12:39 +0200
Nogah Frankel <nogahf@mellanox.com> wrote:
> Add extended stats option for ifstat. It supports stats that are in the
> nesting level as the "normal" stats or one lower, as long as they are in
> the same struct type as the "normal" stats.
> Every extension is unaware of data from other extension and is being
> presented by itself.
> The extension can be called by its name or any shorten of it. If there is
> more then one matched, the first one will be picked.
>
> To get the extended stats the flag -x <stats type> is used.
>
> Signed-off-by: Nogah Frankel <nogahf@mellanox.com>
> Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Finally clearing up iproute2 patch backlog. This feature looks good,
but does not apply cleanly to current git master branch.
--- misc/ifstat.c
+++ misc/ifstat.c
@@ -733,7 +790,8 @@ static void usage(void)
" -s, --noupdate don\'t update history\n"
" -t, --interval=SECS report average over the last SECS\n"
" -V, --version output version information\n"
-" -z, --zeros show entries with zero activity\n");
+" -z, --zeros show entries with zero activity\n"
+" -x, --extended=TYPE show extended stats of TYPE\n");
exit(-1);
}
Please rebase your patches and resubmit.
^ 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