Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

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

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

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

Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

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. >

Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

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

Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

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

Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

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

Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

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

Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

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:

Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

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

[PATCH] net: phy: bcm7xxx: Add entries for Broadcom BCM7346 and BCM7362

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

[PATCH v2] netpoll: Fix extra refcount release in netpoll_cleanup()

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

[PATCH net-next] phy: keep the BCMR_LOOPBACK bit while setup forced mode

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 ---

[RFC PATCH V2 0/2] basic device IOTLB support

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

[RFC PATCH V2 2/2] vhost: device IOTLB API

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: -

[RFC PATCH V2 1/2] vhost: convert pre sorted vhost memory array to interval tree

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

Re: [PATCH net] net: ipv4: Multipath needs to handle unreachable nexthops

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.

Re: [RFT Patch net 1/2] ipv6: invalidate the socket cached route on pmtu events if possible

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

Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

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

Re: [RFC PATCH] tcp: Add SOF_TIMESTAMPING_TX_EOR and allow MSG_EOR in tcp_sendmsg

> 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

Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

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

Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

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

Re: [RFC PATCH 7/9] GSO: Support partial segmentation offload

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

Re: [net-next RFC 0/4] SO_BINDTOSUBNET

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

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

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

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

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

Re: [RFT Patch net 1/2] ipv6: invalidate the socket cached route on pmtu events if possible

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, >> -

Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

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

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

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

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

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[] = { >>> /*

Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

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,

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

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,

Re: [RFC PATCH 7/9] GSO: Support partial segmentation offload

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

[PATCH net] bpf: add missing map_flags to bpf_map_show_fdinfo

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

Re: [RFC PATCH 7/9] GSO: Support partial segmentation offload

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

Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

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

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

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] */ >

[RFC PATCH] tcp: Add SOF_TIMESTAMPING_TX_EOR and allow MSG_EOR in tcp_sendmsg

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

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

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

RE: [PATCH net-next,V2] Add LAN9352 Ethernet Driver

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

Re: [PATCH net] net: ipv4: Multipath needs to handle unreachable nexthops

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

Re: [PATCH net-next,V2] Add LAN9352 Ethernet Driver

> 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

veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."

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

Re: [RFC PATCH 7/9] GSO: Support partial segmentation offload

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

Re: [RFT Patch net 1/2] ipv6: invalidate the socket cached route on pmtu events if possible

> + 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

RE: [PATCH net-next,V2] Add LAN9352 Ethernet Driver

> -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 { >

Re: [RFT Patch net 1/2] ipv6: invalidate the socket cached route on pmtu events if possible

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

Re: [RFC PATCH 7/9] GSO: Support partial segmentation offload

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

Re: [PATCH] ipv6: Fix the pmtu path for connected UDP socket

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.

Re: [RFT Patch net 2/2] ipv6: add a socket release callback for datagram sockets

On Thu, Mar 24, 2016 at 12:25 PM, Cong Wang wrote: > + dst = ip6_dst_lookup_flow(sk, , final_p); > + dst = !IS_ERR(rt) ? >dst : NULL; Oops, this one is clearly a copy-n-paste mistake...

[RFT Patch net 2/2] ipv6: add a socket release callback for datagram sockets

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

[RFT Patch net 1/2] ipv6: invalidate the socket cached route on pmtu events if possible

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

Re: [PATCH] ipv6: Fix the pmtu path for connected UDP socket

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

Re: [PATCH net v2 2/2] net: bcmgenet: fix skb_len in bcmgenet_xmit_single()

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

Re: [PATCH net v2 1/2] net: bcmgenet: fix dev->stats.tx_bytes accounting

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. >

Re: [PATCH] netpoll: Fix extra refcount release in netpoll_cleanup()

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

Re: [PATCH net] switchdev: fix typo in comments/doc

From: Nicolas Dichtel Date: Thu, 24 Mar 2016 16:50:00 +0100 > Two minor typo. > > Signed-off-by: Nicolas Dichtel Applied, thank you.

Re: [PATCH 1/1] net: macb: replace macb_writel() call by queue_writel() to update queue ISR

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

Re: [PATCH 0/3] Control ethernet PHY LEDs via LED subsystem

> 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

Re: [RFC PATCH 7/9] GSO: Support partial segmentation offload

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

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

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

Re: [PATCH net 0/7] net: hns: fix some bugs in HNS driver

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

Re: [PATCH] ipv6: Fix the pmtu path for connected UDP socket

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

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

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

Re: [PATCH net v2 RESEND] xfrm: Fix crash observed during device unregistration and decryption

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

[PATCH net v2 1/2] net: bcmgenet: fix dev->stats.tx_bytes accounting

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

[PATCH net v2 2/2] net: bcmgenet: fix skb_len in bcmgenet_xmit_single()

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

Re: [PATCH net] net: ipv4: Multipath needs to handle unreachable nexthops

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

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

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

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

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

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

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

Re: [PATCH 1/1] net: macb: remove BUG_ON() and reset the queue to handle RX errors

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

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

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 @@

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

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 +++

Re: [PATCH net] net: ipv4: Multipath needs to handle unreachable nexthops

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

Re: [PATCH net] net: ipv4: Multipath needs to handle unreachable nexthops

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

Re: [PATCH 0/3] Control ethernet PHY LEDs via LED subsystem

>> >> 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

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

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

Re: [RFC PATCH 7/9] GSO: Support partial segmentation offload

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

Re: [PATCH] stmmac: Fix phy without MDIO subnode

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

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

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, >

RE: [PATCH v2] mwifiex: advertise low priority scan feature

> 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

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

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; > >

Re: [PATCH net] net: ipv4: Multipath needs to handle unreachable nexthops

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 > --- >

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

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

[PATCH] netpoll: Fix extra refcount release in netpoll_cleanup()

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

[PATCH net] net: ipv4: Multipath needs to handle unreachable nexthops

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]

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

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

[PATCH iproute2 master 1/2] vxlan: add support to set flow label

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 -

[PATCH net] switchdev: fix typo in comments/doc

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

[PATCH iproute2 master 2/2] geneve: add support to set flow label

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

[PATCH iproute2 master 0/2] setting flow label support

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

Re: [PATCH 1/1] net: macb: replace macb_writel() call by queue_writel() to update queue ISR

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 >

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

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

[PATCH 1/1] net: macb: replace macb_writel() call by queue_writel() to update queue ISR

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

Re: [PATCH 1/1] net: macb: remove BUG_ON() and reset the queue to handle RX errors

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

Re: [RFD] workqueue: WQ_MEM_RECLAIM usage in network drivers

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,

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

Hi Eric, On Thu, Mar 24, 2016 at 07:13:33AM -0700, Eric Dumazet wrote: > On Thu, 2016-03-24 at 07:12 +0100, Willy Tarreau wrote: > > Hi, > > > > On Wed, Mar 23, 2016 at 10:10:06PM -0700, Tolga Ceylan wrote: > > > I apologize for not properly following up on this. I had the > > > impression that

[PATCH 1/1] net: macb: remove BUG_ON() and reset the queue to handle RX errors

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 before restarting the reception from a clean state. This

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

On Thu, 2016-03-24 at 07:12 +0100, Willy Tarreau wrote: > Hi, > > On Wed, Mar 23, 2016 at 10:10:06PM -0700, Tolga Ceylan wrote: > > I apologize for not properly following up on this. I had the > > impression that we did not want to merge my original patch and then I > > also noticed that it fails

Re: [PATCH] net: phy: at803x: Request 'reset' GPIO only for AT8030 PHY

On 03/24/2016 01:10 PM, Sebastian Frias wrote: What I don't understand is why the link_change_notify() method ptr is populated for all 3 supported chips while only being needed on 8030... You are right. I made the patch but I'm unsure about it because it could conflict with yours. I

  1   2   >