On Fri, 2016-03-25 at 06:28 +0100, Willy Tarreau wrote:
> On Thu, Mar 24, 2016 at 04:54:03PM -0700, Tom Herbert wrote:
> > On Thu, Mar 24, 2016 at 4:40 PM, Yann Ylavic wrote:
> > > I'll learn how to do this to get the best performances from the
> > > server, but having to do so to work around what
> -Original Message-
> From: Scott Wood
> Sent: Saturday, March 19, 2016 2:28 AM
> To: Arnd Bergmann; Rob Herring
> Cc: Yangbo Lu; linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org;
> ulf.hans...@linaro.org; Zhao Qiang; Russell King; Bhupesh Sharma;
> netdev@vger.kernel.org; Joerg R
> -Original Message-
> From: Scott Wood
> Sent: Saturday, March 19, 2016 2:16 AM
> To: Rob Herring; Yangbo Lu
> Cc: devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-ker...@vger.kernel.org; linuxppc-...@lists.ozlabs.org; linux-
> c...@vger.kernel.org; linux-...@vger.
On Thu, Mar 24, 2016 at 10:13 PM, Ben Greear wrote:
>
>
> On 03/24/2016 10:06 PM, Cong Wang wrote:
>>
>> On Thu, Mar 24, 2016 at 9:34 PM, Ben Greear
>> wrote:
>>>
>>>
>>>
>>> On 03/24/2016 06:44 PM, Vijay Pandurangan wrote:
Oops, I think my last email didn't go through due to an in
On Thu, Mar 24, 2016 at 04:54:03PM -0700, Tom Herbert wrote:
> On Thu, Mar 24, 2016 at 4:40 PM, Yann Ylavic wrote:
> > I'll learn how to do this to get the best performances from the
> > server, but having to do so to work around what looks like a defect
> > (for simple/default SMP configurations
On Fri, Mar 25, 2016 at 1:07 AM, Ben Greear wrote:
> On 03/24/2016 09:45 PM, Vijay Pandurangan wrote:
>>
>> Actually, maybe they should be set to CHECKSUM_PARTIAL if we want veth
>> to drop the packets if they have bad checksums before they hit the
>> application level.
>
>
> VETH is pretty specia
On 03/24/2016 10:06 PM, Cong Wang wrote:
On Thu, Mar 24, 2016 at 9:34 PM, Ben Greear wrote:
On 03/24/2016 06:44 PM, Vijay Pandurangan wrote:
Oops, I think my last email didn't go through due to an inadvertent
html attachment from my phone mail client.
Can you send us a copy of a packet y
On 03/24/2016 09:45 PM, Vijay Pandurangan wrote:
Actually, maybe they should be set to CHECKSUM_PARTIAL if we want veth
to drop the packets if they have bad checksums before they hit the
application level.
VETH is pretty special in that when you transmit a frame on one
device, it's pair receive
On Thu, Mar 24, 2016 at 9:34 PM, Ben Greear wrote:
>
>
> On 03/24/2016 06:44 PM, Vijay Pandurangan wrote:
>>
>> Oops, I think my last email didn't go through due to an inadvertent
>> html attachment from my phone mail client.
>>
>> Can you send us a copy of a packet you're sending and/or confirm t
Actually, maybe they should be set to CHECKSUM_PARTIAL if we want veth
to drop the packets if they have bad checksums before they hit the
application level.
On Fri, Mar 25, 2016 at 12:41 AM, Vijay Pandurangan wrote:
> agreed. It should maybe be set to CHECKSUM_UNNECESSARY. The comment
> seems to
agreed. It should maybe be set to CHECKSUM_UNNECESSARY. The comment
seems to imply that it's treated the same as CHECKSUM_NONE but that's
evidently not true. I think that would fix the checksumming issue but
I'm fearful it may break something else:
http://lxr.free-electrons.com/source/include/linux
On 03/24/2016 06:44 PM, Vijay Pandurangan wrote:
Oops, I think my last email didn't go through due to an inadvertent
html attachment from my phone mail client.
Can you send us a copy of a packet you're sending and/or confirm that
the IP and UDP4 checksums are set correctly in the packet?
If t
Add PHY entries for the Broadcom BCM7346 and BCM7362 chips, these are
40nm generation Ethernet PHY.
Fixes: 815717d1473e ("net: phy: bcm7xxx: Remove wildcard entries")
Signed-off-by: Jaedon Shin
---
drivers/net/phy/bcm7xxx.c | 4
include/linux/brcmphy.h | 2 ++
2 files changed, 6 insertion
netpoll_setup() does a dev_hold() on np->dev, the netpoll device. If it
fails, it correctly does a dev_put() but leaves np->dev set. If we call
netpoll_cleanup() after the failure, np->dev is still set so we do another
dev_put(), which decrements the refcount an extra time.
It's questionable to
When tested the PHY SGMII Loopback,:
1.set the LOOPBACK bit,
2.set the autoneg to AUTONEG_DISABLE, it calls the
genphy_setup_forced which will clear the bit.
So just keep the LOOPBACK bit while setup forced mode.
Signed-off-by: Weidong Wang
---
drivers/net/phy/phy_device.c | 2 ++
1 file change
This patch tries to implement an device IOTLB for vhost. This could be
used with for co-operation with userspace(qemu) implementation of
iommu for a secure DMA environment (DMAR) in guest.
The idea is simple. When vhost meets an IOTLB miss, it will request
the assistance of userspace to do the tra
This patch tries to implement an device IOTLB for vhost. This could be
used with for co-operation with userspace(qemu) implementation of DMA
remapping.
The idea is simple. When vhost meets an IOTLB miss, it will request
the assistance of userspace to do the translation, this is done
through:
- Fi
Current pre-sorted memory region array has some limitations for future
device IOTLB conversion:
1) need extra work for adding and removing a single region, and it's
expected to be slow because of sorting or memory re-allocation.
2) need extra work of removing a large range which may intersect
On 3/24/16 4:33 PM, Julian Anastasov wrote:
But for multipath routes we can also consider the
nexthops as "alternatives", so it depends on how one uses
the multipath mechanism. The ability to fallback to
another nexthop assumes one connection is allowed to
move from one ISP to another. Wh
On Thu, 2016-03-24 at 17:15 -0700, Cong Wang wrote:
> My understanding is that bh_lock_sock() prevents concurrent
> access to sock struct. Since this is in softirq context, multiple
> CPU's could call this function concurrently, the whole pmtu
> update needs to be done atomically.
>
> UDP, on the
Oops, I think my last email didn't go through due to an inadvertent
html attachment from my phone mail client.
Can you send us a copy of a packet you're sending and/or confirm that
the IP and UDP4 checksums are set correctly in the packet?
If those are set right, I think we need to read through t
> This patch allows the user process to use MSG_EOR during
> tcp_sendmsg to tell the kernel that it is the last byte
> of an application response message.
>
> The user process can use the new SOF_TIMESTAMPING_TX_EOR to
> ask the kernel to only track timestamp of the MSG_EOR byte.
Selective timesta
On 03/24/2016 06:11 PM, Ben Greear wrote:
On 03/24/2016 05:06 PM, Ben Greear wrote:
On 03/24/2016 04:56 PM, Cong Wang wrote:
On Thu, Mar 24, 2016 at 3:01 PM, Ben Greear wrote:
I have an application that creates two pairs of veth devices.
a <-> b c <-> d
b and c have a raw packet socke
On 03/24/2016 05:06 PM, Ben Greear wrote:
On 03/24/2016 04:56 PM, Cong Wang wrote:
On Thu, Mar 24, 2016 at 3:01 PM, Ben Greear wrote:
I have an application that creates two pairs of veth devices.
a <-> b c <-> d
b and c have a raw packet socket opened on them and I 'bridge' frames
betw
On Thu, 24 Mar 2016, Alexander Duyck wrote:
> On Thu, Mar 24, 2016 at 4:00 PM, Edward Cree wrote:
>> So: in the initial transmit path we build a coherent superframe; when we get
>> to the device, we say either "oh, device doesn't support offloads at all,
>> call GSO", or "oh, device supports this
On Wed, Mar 16, 2016 at 6:19 AM, Gilberto Bertin
wrote:
> This is my second attempt to submit an RFC for this patch.
>
> Some arguments for and against it since the first submission:
> * SO_BINDTOSUBNET is an arbitrary option and can be seens as nother use
> * case of the SO_REUSEPORT BPF patch
>
From: Yann Ylavic
Date: Thu, 24 Mar 2016 23:40:30 +0100
> On Thu, Mar 24, 2016 at 6:55 PM, Daniel Borkmann wrote:
>> On 03/24/2016 06:26 PM, Tom Herbert wrote:
>>>
>>> On Thu, Mar 24, 2016 at 10:01 AM, Eric Dumazet wrote:
Really, when BPF can be the solution, we wont allow adding new st
From: Eric Dumazet
Date: Thu, 24 Mar 2016 15:49:48 -0700
> That is why EBPF has LLVM backend.
>
> Basically you can write your "BPF" program in C, and let llvm convert it
> into EBPF.
>
> Sure, you still can write BPF manually, as you could write HTTPS server
> in assembly.
+1
On Thu, Mar 24, 2016 at 1:35 PM, Eric Dumazet wrote:
> On Thu, 2016-03-24 at 12:25 -0700, Cong Wang wrote:
>
>> void ip6_sk_update_pmtu(struct sk_buff *skb, struct sock *sk, __be32 mtu)
>> {
>> - ip6_update_pmtu(skb, sock_net(sk), mtu,
>> - sk->sk_bound_dev_if, sk->sk_mar
On 03/24/2016 04:56 PM, Cong Wang wrote:
On Thu, Mar 24, 2016 at 3:01 PM, Ben Greear wrote:
I have an application that creates two pairs of veth devices.
a <-> b c <-> d
b and c have a raw packet socket opened on them and I 'bridge' frames
between b and c to provide network emulation (i
On Fri, Mar 25, 2016 at 12:54 AM, Tom Herbert wrote:
> On Thu, Mar 24, 2016 at 4:40 PM, Yann Ylavic wrote:
>>
>> From this POV, draining the (ending) listeners is already non obvious
>> but might be reasonable, (e)BPF sounds really overkill.
>>
> Just the opposite, it's a simplification. With BPF
On Thu, Mar 24, 2016 at 4:40 PM, Yann Ylavic wrote:
> On Thu, Mar 24, 2016 at 11:49 PM, Eric Dumazet wrote:
>> On Thu, 2016-03-24 at 23:40 +0100, Yann Ylavic wrote:
>>
>>> FWIW, I find:
>>>
>>> const struct bpf_insn prog[] = {
>>> /* BPF_MOV64_REG(BPF_REG_6, BPF_REG_1) */
>>>
On Thu, Mar 24, 2016 at 3:01 PM, Ben Greear wrote:
> I have an application that creates two pairs of veth devices.
>
> a <-> b c <-> d
>
> b and c have a raw packet socket opened on them and I 'bridge' frames
> between b and c to provide network emulation (ie, configurable delay).
>
IIUC, y
On Thu, Mar 24, 2016 at 11:49 PM, Eric Dumazet wrote:
> On Thu, 2016-03-24 at 23:40 +0100, Yann Ylavic wrote:
>
>> FWIW, I find:
>>
>> const struct bpf_insn prog[] = {
>> /* BPF_MOV64_REG(BPF_REG_6, BPF_REG_1) */
>> { BPF_ALU64 | BPF_MOV | BPF_X, BPF_REG_6, BPF_REG_1, 0, 0 },
>
On Thu, Mar 24, 2016 at 4:00 PM, Edward Cree wrote:
> On 24/03/16 21:50, Alexander Duyck wrote:
>> On Thu, Mar 24, 2016 at 1:17 PM, Edward Cree wrote:
>>> (Besides, I thought it was impossible for the partial checksum to be zero
>>> anyway because at least one of the inputs must be nonzero, and t
Add map_flags attribute to bpf_map_show_fdinfo(), so that tools like
tc can check for them when loading objects from a pinned entry, e.g.
if user intent wrt allocation (BPF_F_NO_PREALLOC) is different to the
pinned object, it can bail out. Follow-up to 6c9059817432 ("bpf:
pre-allocate hash map elem
On 24/03/16 21:50, Alexander Duyck wrote:
> On Thu, Mar 24, 2016 at 1:17 PM, Edward Cree wrote:
>> (Besides, I thought it was impossible for the partial checksum to be zero
>> anyway because at least one of the inputs must be nonzero, and the end-
>> around carry can never produce a zero. But may
On 03/24/2016 03:49 PM, Vijay Pandurangan wrote:
Hmm that's troubling. We tested various UDP configurations but I don't think we
tested this setup. Do you have code or more specific instructions we can use to
replicate this bug?
The user-space app is not open source, and the routing setup is
a
On Thu, 2016-03-24 at 23:40 +0100, Yann Ylavic wrote:
> FWIW, I find:
>
> const struct bpf_insn prog[] = {
> /* BPF_MOV64_REG(BPF_REG_6, BPF_REG_1) */
> { BPF_ALU64 | BPF_MOV | BPF_X, BPF_REG_6, BPF_REG_1, 0, 0 },
> /* BPF_LD_ABS(BPF_W, 0) R0 = (uint32_t)skb[0] */
>
This patch extends the SO_TIMESTAMPING work and the primary
objective is to track when TCP ACK is received for the
last byte of an application's message (e.g. HTTP2).
This patch allows the user process to use MSG_EOR during
tcp_sendmsg to tell the kernel that it is the last byte
of an application
On Thu, Mar 24, 2016 at 6:55 PM, Daniel Borkmann wrote:
> On 03/24/2016 06:26 PM, Tom Herbert wrote:
>>
>> On Thu, Mar 24, 2016 at 10:01 AM, Eric Dumazet wrote:
>>>
>>> Really, when BPF can be the solution, we wont allow adding new stuff in
>>> the kernel in the old way.
>>
>> I completely agree wi
On March 24, 2016 2:16:30 PM PDT, bryan.whiteh...@microchip.com wrote:
>> -Original Message-
>Hi Andrew,
>
>Sorry to bother you with this. But I'm having major difficulty with
>getting my dsa driver entry points called.
>
>Here is what I've done so far.
>
>I copied drivers/net/dsa/mv88x6060
Hello,
On Thu, 24 Mar 2016, David Ahern wrote:
> Multipath route lookups should consider knowledge about next hops and not
> select a hop that is known to be failed.
...
> The failed path can be avoided by considering known neighbor information
> when selecting next hops. If the neighb
> It appears the dsa.c is not able to attach my underlying net
> device. And that seems to be due to it is unable to find the
> mdio_bus.
> So I modified my net device driver so that in probe it calls
> of_mdiobus_register instead of mdiobus_register.
> And of_mdiobus_register seems to be lookin
I have an application that creates two pairs of veth devices.
a <-> b c <-> d
b and c have a raw packet socket opened on them and I 'bridge' frames
between b and c to provide network emulation (ie, configurable delay).
I put IP 1.1.1.1/24 on a, 1.1.1.2/24 on d, and then create a UDP conn
On Thu, Mar 24, 2016 at 1:17 PM, Edward Cree wrote:
> On 24/03/16 18:43, Alexander Duyck wrote:
>> On Thu, Mar 24, 2016 at 10:12 AM, Edward Cree wrote:
>>> For UDP header, we look to see if the current checksum field is zero. If
>>> so, we leave it as zero, fold our edits into csum_edit and retu
> + if (new)
> + ip6_dst_store(sk, dst, NULL, NULL);
> +
I read through the code for ip6_dst_store(), the last 2 params are for
sk->daddr_cache and sk->saddr_cache.
Those are examined and used in ip6_sk_dst_lookup_flow(). If those 2
(mostly only check sk->daddr_cache) are valid,
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Friday, February 19, 2016 3:14 PM
> > I'm not yet sure how it attaches to the underlying Ethernet driver.
>
> The DSA core does that for you. If you look at the device tree
> binding:
>
> dsa@0 {
>
On Thu, 2016-03-24 at 12:25 -0700, Cong Wang wrote:
> void ip6_sk_update_pmtu(struct sk_buff *skb, struct sock *sk, __be32 mtu)
> {
> - ip6_update_pmtu(skb, sock_net(sk), mtu,
> - sk->sk_bound_dev_if, sk->sk_mark);
> + const struct ipv6hdr *iph = (struct ipv6hdr *)skb
On 24/03/16 18:43, Alexander Duyck wrote:
> On Thu, Mar 24, 2016 at 10:12 AM, Edward Cree wrote:
>> For UDP header, we look to see if the current checksum field is zero. If
>> so, we leave it as zero, fold our edits into csum_edit and return the
>> result. Otherwise, we fold our edits and csum_e
On Thu, Mar 24, 2016 at 11:32:28AM -0700, Martin KaFai Lau wrote:
> Some fast path may do __sk_dst_get() which does not refcnt the
> sk->sk_dst_cache.
Ignore this comment. This should have been protected by rcu grace period.
On Thu, Mar 24, 2016 at 12:25 PM, Cong Wang wrote:
> + dst = ip6_dst_lookup_flow(sk, &fl6, final_p);
> + dst = !IS_ERR(rt) ? &rt->dst : NULL;
Oops, this one is clearly a copy-n-paste mistake...
Similar to commit 8141ed9fcedb, this implements a socket
release callback function to check if an IPv6 socket cached
route got invalid during the time we owned the socket.
The function is used from udp, raw sockets.
Cc: Steffen Klassert
Cc: Martin KaFai Lau
Cc: Hannes Frederic Sowa
Cc: Steffen
Similar to commit 9cb3a50c5f63, with this patch we invalidate the
socket cached route if possible. If the socket is owened by the
user, we can't update the cached route directly.
Reported-by: Wei Wang
Cc: Steffen Klassert
Cc: Martin KaFai Lau
Cc: Hannes Frederic Sowa
Cc: Steffen Klassert
Cc:
On Tue, Mar 22, 2016 at 4:36 PM, Eric Dumazet wrote:
> On Tue, 2016-03-22 at 13:13 -0700, Cong Wang wrote:
>> On Tue, Mar 22, 2016 at 11:03 AM, Wei Wang wrote:
>> > Thanks Martin and Cong.
>> >
>> > I guess then we are going with the following fix in ip6_sk_update_pmtu():
>> > 1. call ip6_upate_p
From: Petri Gynther
Date: Thu, 24 Mar 2016 11:27:21 -0700
> skb_len needs to be skb_headlen(skb) in bcmgenet_xmit_single().
>
> Fragmented skbs can have only Ethernet + IP + TCP headers (14+20+20=54 bytes)
> in the linear buffer, followed by the rest in fragments. Bumping skb_len to
> ETH_ZLEN w
From: Petri Gynther
Date: Thu, 24 Mar 2016 11:27:20 -0700
> 1. Add bytes_compl local variable to __bcmgenet_tx_reclaim() to collect
>transmitted bytes. dev->stats updates can then be moved outside the
>while-loop. bytes_compl is also needed for future BQL support.
> 2. When bcmgenet devic
From: Bjorn Helgaas
Date: Thu, 24 Mar 2016 11:13:34 -0500
> netpoll_setup() does a dev_hold() on np->dev, the netpoll device. If it
> fails, it correctly does a dev_put() but leaves np->dev set. If we call
> netpoll_cleanup() after the failure, np->dev is still set so we do another
> dev_put(),
From: Nicolas Dichtel
Date: Thu, 24 Mar 2016 16:50:00 +0100
> Two minor typo.
>
> Signed-off-by: Nicolas Dichtel
Applied, thank you.
From: Cyrille Pitchen
Date: Thu, 24 Mar 2016 15:40:04 +0100
> macb_interrupt() should not use macb_writel(bp, ISR, ) but only
> queue_writel(queue, ISR, ).
>
> There is one IRQ and one set of {ISR, IER, IDR, IMR} [1] registers per
> queue on gem hardware, though only queue0 is actually used for
> Hi Andrew,
>
> I still have some questions. Will the phylib call this
> led_trigger_register_to_led() function for registering the trigger
> instead of calling led_trigger_register()?
Each phy driver needs to call led_classdev_register() for each LED it
has. It then also calls led_trigger_regis
On Thu, Mar 24, 2016 at 10:12 AM, Edward Cree wrote:
> On 23/03/16 23:15, Alexander Duyck wrote:
>> Right, but the problem becomes how do you identify what tunnel wants
>> what. So for example we could theoretically have a UDP tunnel in a
>> UDP with checksum. How would we tell which one want to
On Thu, 2016-03-24 at 11:20 -0700, Tolga Ceylan wrote:
> On Thu, Mar 24, 2016 at 10:55 AM, Daniel Borkmann
> wrote:
> > On 03/24/2016 06:26 PM, Tom Herbert wrote:
> >>
> >> I completely agree with this, but I wonder if we now need a repository
> >> of useful BPF modules. So in the case of impleme
From: Yisen Zhuang
Date: Thu, 24 Mar 2016 19:07:59 +0800
> Here are some bug fixed patches for HNS driver.
>
> They are:
>
>>from Kejian, fix for the warning of passing zero to 'PTR_ERR'
>
>>from qianqian, four fixes for inappropriate operation in hns driver
>
>>from Sheng, one fix for optimi
On Wed, Mar 23, 2016 at 04:57:22PM -0700, Wei Wang wrote:
> What about something like this:
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index ed44663..21b4102 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -1394,6 +1394,19 @@ static void ip6_rt_update_pmtu(struct dst_entry
On Thu, 2016-03-24 at 19:00 +0100, Willy Tarreau wrote:
> OK so this means we have to find a way to expand it to allow an individual
> non-privileged process to change the distribution algorithm without impacting
> other processes.
Just to clarify : Installing a BPF filter on a SO_REUSEPORT socke
From: Subash Abhinov Kasiviswanathan
Date: Wed, 23 Mar 2016 22:39:50 -0600
> A crash is observed when a decrypted packet is processed in receive
> path. get_rps_cpus() tries to dereference the skb->dev fields but it
> appears that the device is freed from the poison pattern.
...
> Following are
1. Add bytes_compl local variable to __bcmgenet_tx_reclaim() to collect
transmitted bytes. dev->stats updates can then be moved outside the
while-loop. bytes_compl is also needed for future BQL support.
2. When bcmgenet device uses Tx checksum offload, each transmitted skb
gets an extra 64
skb_len needs to be skb_headlen(skb) in bcmgenet_xmit_single().
Fragmented skbs can have only Ethernet + IP + TCP headers (14+20+20=54 bytes)
in the linear buffer, followed by the rest in fragments. Bumping skb_len to
ETH_ZLEN would be incorrect for this case, as it would introduce garbage
between
From: Eric Dumazet
Date: Thu, 24 Mar 2016 09:45:34 -0700
> On Thu, 2016-03-24 at 08:25 -0700, David Ahern wrote:
>> Multipath route lookups should consider knowledge about next hops and not
>> select a hop that is known to be failed.
>
> Does not look a net candidate to me.
>
>> Signed-off-by:
On Thu, Mar 24, 2016 at 11:20:49AM -0700, Tolga Ceylan wrote:
> I would appreciate a conceptual description on how this would work
> especially for a common scenario
> as described by Willy. My initial impression was that a coordinator
> (master) process takes this
> responsibility to adjust BPF fi
On Thu, Mar 24, 2016 at 07:00:11PM +0100, Willy Tarreau wrote:
> Since it's not about
> load distribution and that processes are totally independant, I don't see
> well how to (ab)use BPF to achieve this.
>
> The pattern is :
>
> t0 : unprivileged processes 1 and 2 are listening to the same por
On Thu, Mar 24, 2016 at 10:55 AM, Daniel Borkmann wrote:
> On 03/24/2016 06:26 PM, Tom Herbert wrote:
>>
>> I completely agree with this, but I wonder if we now need a repository
>> of useful BPF modules. So in the case of implementing functionality
>> like in SO_REUSEPORT_LISTEN_OFF that might ju
Hello.
On 03/24/2016 05:37 PM, Cyrille Pitchen wrote:
This patch removes two BUG_ON() used to notify about RX queue corruptions
on macb (not gem) hardware without actually handling the error.
The new code skips corrupted frames but still processes faultless frames.
Then it resets the RX queue
On Thu, Mar 24, 2016 at 10:01:37AM -0700, Eric Dumazet wrote:
> On Thu, 2016-03-24 at 17:50 +0100, Willy Tarreau wrote:
> > On Thu, Mar 24, 2016 at 09:33:11AM -0700, Eric Dumazet wrote:
> > > > --- a/net/ipv4/inet_hashtables.c
> > > > +++ b/net/ipv4/inet_hashtables.c
> > > > @@ -189,6 +189,8 @@ sta
On 03/24/2016 06:26 PM, Tom Herbert wrote:
On Thu, Mar 24, 2016 at 10:01 AM, Eric Dumazet wrote:
On Thu, 2016-03-24 at 17:50 +0100, Willy Tarreau wrote:
On Thu, Mar 24, 2016 at 09:33:11AM -0700, Eric Dumazet wrote:
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -189,6 +1
On Thu, 2016-03-24 at 11:43 -0600, David Ahern wrote:
> On 3/24/16 10:45 AM, Eric Dumazet wrote:
> > On Thu, 2016-03-24 at 08:25 -0700, David Ahern wrote:
> >> Multipath route lookups should consider knowledge about next hops and not
> >> select a hop that is known to be failed.
> >
> > Does not lo
On 3/24/16 10:45 AM, Eric Dumazet wrote:
On Thu, 2016-03-24 at 08:25 -0700, David Ahern wrote:
Multipath route lookups should consider knowledge about next hops and not
select a hop that is known to be failed.
Does not look a net candidate to me.
you don't consider this a bug? certainly not
>> >> The eth-phy-activity trigger uses the blink_set which I think uses the
>> >> hardware acceleration if available. I am not sure how to handles LEDs
>> >> which does not have hardware acceleration for this (eth-phy-activity)
>> >> trigger.
>> >
>> > We want the LED to blink on activity, real pa
On Thu, Mar 24, 2016 at 10:01 AM, Eric Dumazet wrote:
> On Thu, 2016-03-24 at 17:50 +0100, Willy Tarreau wrote:
>> On Thu, Mar 24, 2016 at 09:33:11AM -0700, Eric Dumazet wrote:
>> > > --- a/net/ipv4/inet_hashtables.c
>> > > +++ b/net/ipv4/inet_hashtables.c
>> > > @@ -189,6 +189,8 @@ static inline
On 23/03/16 23:15, Alexander Duyck wrote:
> Right, but the problem becomes how do you identify what tunnel wants
> what. So for example we could theoretically have a UDP tunnel in a
> UDP with checksum. How would we tell which one want to have the
> checksum set and which one doesn't? The fact i
On Thu, 24 Mar 2016 13:56:02 +0100, Giuseppe CAVALLARO wrote:
> This should be fixed by some work done some days
> ago and not yet committed.
>
> Pls see "stmmac: MDIO fixes" patch-set and let me know
> if ok on your side.
Yes, that works for me.
Thanks,
John
> On 3/24/2016 11:56 AM, John Kee
On Thu, 2016-03-24 at 17:50 +0100, Willy Tarreau wrote:
> On Thu, Mar 24, 2016 at 09:33:11AM -0700, Eric Dumazet wrote:
> > > --- a/net/ipv4/inet_hashtables.c
> > > +++ b/net/ipv4/inet_hashtables.c
> > > @@ -189,6 +189,8 @@ static inline int compute_score(struct sock *sk,
> > > struct net *net,
>
> From: Wei-Ning Huang [mailto:wnhu...@chromium.org]
> Sent: Tuesday, March 22, 2016 9:40 AM
> To: Linux Wireless
> Cc: LKML; Amitkumar Karwar; djku...@chromium.org; Wei-Ning Huang;
> Nishant Sarmukadam; kv...@codeaurora.org; netdev@vger.kernel.org
> Subject: [PATCH v2] mwifiex: advertise low prior
On Thu, Mar 24, 2016 at 09:33:11AM -0700, Eric Dumazet wrote:
> > --- a/net/ipv4/inet_hashtables.c
> > +++ b/net/ipv4/inet_hashtables.c
> > @@ -189,6 +189,8 @@ static inline int compute_score(struct sock *sk, struct
> > net *net,
> > return -1;
> >
On Thu, 2016-03-24 at 08:25 -0700, David Ahern wrote:
> Multipath route lookups should consider knowledge about next hops and not
> select a hop that is known to be failed.
Does not look a net candidate to me.
> Signed-off-by: David Ahern
> ---
> net/ipv4/fib_semantics.c | 34 ++
On Thu, 2016-03-24 at 16:30 +0100, Willy Tarreau wrote:
> Hi Eric,
>
> (just lost my e-mail, trying not to forget some points)
>
> On Thu, Mar 24, 2016 at 07:45:44AM -0700, Eric Dumazet wrote:
> > On Thu, 2016-03-24 at 15:22 +0100, Willy Tarreau wrote:
> > > Hi Eric,
> >
> > > But that means th
netpoll_setup() does a dev_hold() on np->dev, the netpoll device. If it
fails, it correctly does a dev_put() but leaves np->dev set. If we call
netpoll_cleanup() after the failure, np->dev is still set so we do another
dev_put(), which decrements the refcount an extra time.
It's questionable to
Multipath route lookups should consider knowledge about next hops and not
select a hop that is known to be failed.
Example:
[h2] [h3] 15.0.0.5
| |
3| 3|
[SP1]
Hi Eric,
(just lost my e-mail, trying not to forget some points)
On Thu, Mar 24, 2016 at 07:45:44AM -0700, Eric Dumazet wrote:
> On Thu, 2016-03-24 at 15:22 +0100, Willy Tarreau wrote:
> > Hi Eric,
>
> > But that means that any software making use of SO_REUSEPORT needs to
> > also implement BPF
Follow-up for kernel commit e7f70af111f0 ("vxlan: support setting
IPv6 flow label") to allow setting the label for the device config.
Signed-off-by: Daniel Borkmann
---
ip/ip_common.h| 4
ip/iplink_vxlan.c | 29 -
man/man8/ip-link.8.in | 6 ++
3
Two minor typo.
Signed-off-by: Nicolas Dichtel
---
Documentation/networking/switchdev.txt | 2 +-
net/switchdev/switchdev.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/switchdev.txt
b/Documentation/networking/switchdev.txt
index f
Follow-up for kernel commit 8eb3b99554b8 ("geneve: support setting
IPv6 flow label") to allow setting the label for the device config.
Signed-off-by: Daniel Borkmann
---
ip/iplink_geneve.c| 29 -
man/man8/ip-link.8.in | 6 ++
2 files changed, 30 insertions(+)
On top of Jesse's csum patches for vxlan, geneve:
- http://patchwork.ozlabs.org/patch/599746/
- http://patchwork.ozlabs.org/patch/599747/
Thanks!
Daniel Borkmann (2):
vxlan: add support to set flow label
geneve: add support to set flow label
ip/ip_common.h| 4
ip/iplink_g
Le 24/03/2016 15:37, Cyrille Pitchen a écrit :
> This patch removes two BUG_ON() used to notify about RX queue corruptions
> on macb (not gem) hardware without actually handling the error.
>
> The new code skips corrupted frames but still processes faultless frames.
> Then it resets the RX queue b
Le 24/03/2016 15:40, Cyrille Pitchen a écrit :
> macb_interrupt() should not use macb_writel(bp, ISR, ) but only
> queue_writel(queue, ISR, ).
>
> There is one IRQ and one set of {ISR, IER, IDR, IMR} [1] registers per
> queue on gem hardware, though only queue0 is actually used for now to
> receiv
On Thu, 2016-03-24 at 15:22 +0100, Willy Tarreau wrote:
> Hi Eric,
> But that means that any software making use of SO_REUSEPORT needs to
> also implement BPF on Linux to achieve the same as what it does on
> other OSes ? Also I found a case where a dying process would still
> cause trouble in the
macb_interrupt() should not use macb_writel(bp, ISR, ) but only
queue_writel(queue, ISR, ).
There is one IRQ and one set of {ISR, IER, IDR, IMR} [1] registers per
queue on gem hardware, though only queue0 is actually used for now to
receive frames: other queues can already be used to transmit fram
On 03/24/2016 03:37 PM, Cyrille Pitchen wrote:
> This patch removes two BUG_ON() used to notify about RX queue corruptions
> on macb (not gem) hardware without actually handling the error.
>
> The new code skips corrupted frames but still processes faultless frames.
> Then it resets the RX queue b
On Sun, 2016-03-20 at 14:55 -0400, Tejun Heo wrote:
> If everything else is working, I'd be happy to throw in
> WQ_MEM_RECLAIM but I really don't want to add it if it doesn't
> actually achieve the goal. Can a wireless person chime in here?
>
I think for many wireless devices the workqueue, like
1 - 100 of 124 matches
Mail list logo
