Re: [RFC PATCH 0/5] Add driver bpf hook for early packet drop

On Sat, Apr 02, 2016 at 12:47:16PM -0400, Tom Herbert wrote: > Very nice! Do you think this hook will be sufficient to implement a > fast forward patch also? That is the goal, but more work needs to be done of course. It won't be possible with just a single pseudo skb, the driver will need a fast

[PATCH v3 net-next 6/8] ipv6: process socket-level control messages in IPv6

From: Soheil Hassas Yeganeh Process socket-level control messages by invoking __sock_cmsg_send in ip6_datagram_send_ctl for control messages on the SOL_SOCKET layer. This makes sure whenever ip6_datagram_send_ctl is called for udp and raw, we also process socket-level control

[PATCH v3 net-next 8/8] sock: document timestamping via cmsg in Documentation

From: Soheil Hassas Yeganeh Update docs and add code snippet for using cmsg for timestamping. Signed-off-by: Soheil Hassas Yeganeh Acked-by: Willem de Bruijn --- Documentation/networking/timestamping.txt | 48

[PATCH v3 net-next 5/8] ipv4: process socket-level control messages in IPv4

From: Soheil Hassas Yeganeh Process socket-level control messages by invoking __sock_cmsg_send in ip_cmsg_send for control messages on the SOL_SOCKET layer. This makes sure whenever ip_cmsg_send is called in udp, icmp, and raw, we also process socket-level control messages.

[PATCH v3 net-next 7/8] sock: enable timestamping using control messages

From: Soheil Hassas Yeganeh Currently, SOL_TIMESTAMPING can only be enabled using setsockopt. This is very costly when users want to sample writes to gather tx timestamps. Add support for enabling SO_TIMESTAMPING via control messages by using tsflags added in `struct

[PATCH v3 net-next 4/8] sock: accept SO_TIMESTAMPING flags in socket cmsg

From: Soheil Hassas Yeganeh Accept SO_TIMESTAMPING in control messages of the SOL_SOCKET level as a basis to accept timestamping requests per write. This implementation only accepts TX recording flags (i.e., SOF_TIMESTAMPING_TX_HARDWARE, SOF_TIMESTAMPING_TX_SOFTWARE,

[PATCH v3 net-next 2/8] tcp: accept SOF_TIMESTAMPING_OPT_ID for passive TFO

From: Soheil Hassas Yeganeh SOF_TIMESTAMPING_OPT_ID is set to get data-independent IDs to associate timestamps with send calls. For TCP connections, tp->snd_una is used as the starting point to calculate relative IDs. This socket option will fail if set before the handshake

[PATCH v3 net-next 3/8] tcp: use one bit in TCP_SKB_CB to mark ACK timestamps

From: Soheil Hassas Yeganeh Currently, to avoid a cache line miss for accessing skb_shinfo, tcp_ack_tstamp skips socket that do not have SOF_TIMESTAMPING_TX_ACK bit set in sk_tsflags. This is implemented based on an implicit assumption that the SOF_TIMESTAMPING_TX_ACK is set

[PATCH v3 net-next 1/8] sock: break up sock_cmsg_snd into __sock_cmsg_snd and loop

From: Willem de Bruijn To process cmsg's of the SOL_SOCKET level in addition to cmsgs of another level, protocols can call sock_cmsg_send(). This causes a double walk on the cmsghdr list, one for SOL_SOCKET and one for the other level. Extract the inner demultiplex logic

[PATCH v3 net-next 0/8] add TX timestamping via cmsg

From: Soheil Hassas Yeganeh This patch series aim at enabling TX timestamping via cmsg. Currently, to occasionally sample TX timestamping on a socket, applications need to call setsockopt twice: first for enabling timestamps and then for disabling them. This is an unnecessary

Re: [RFC PATCH net 3/4] ipv6: datagram: Update dst cache of a connected datagram sk during pmtu update

On Fri, Apr 01, 2016 at 04:13:41PM -0700, Cong Wang wrote: > On Fri, Apr 1, 2016 at 3:56 PM, Martin KaFai Lau wrote: > > + bh_lock_sock(sk); > > + if (!sock_owned_by_user(sk)) > > + ip6_datagram_dst_update(sk, false); > > + bh_unlock_sock(sk); > > >

Re: [RFC PATCH 0/5] Add driver bpf hook for early packet drop

On Sun, Apr 3, 2016 at 7:57 AM, Tom Herbert wrote: > I am curious though, how do you think this would specifically help > Android with power? Seems like the receiver still needs to be powered > to receive packets to filter them anyway... The receiver is powered up, but its

Re: [PATCH v2 net-next 0/8] add TX timestamping via cmsg

On Sat, Apr 2, 2016 at 9:27 PM, David Miller wrote: > From: David Miller > Date: Sat, 02 Apr 2016 21:19:42 -0400 (EDT) > >> Series applied, thanks. > > I had to revert, this breaks the build: > > net/l2tp/l2tp_ip6.c: In function ‘l2tp_ip6_sendmsg’: >

Re: [PATCH v2 net-next 0/8] add TX timestamping via cmsg

From: David Miller Date: Sat, 02 Apr 2016 21:19:42 -0400 (EDT) > Series applied, thanks. I had to revert, this breaks the build: net/l2tp/l2tp_ip6.c: In function ‘l2tp_ip6_sendmsg’: net/l2tp/l2tp_ip6.c:565:9: error: too few arguments to function ‘ip6_datagram_send_ctl’

Re: [PATCH v2 net-next 0/8] add TX timestamping via cmsg

From: Soheil Hassas Yeganeh Date: Fri, 1 Apr 2016 11:04:32 -0400 > From: Soheil Hassas Yeganeh > > This patch series aim at enabling TX timestamping via cmsg. > > Currently, to occasionally sample TX timestamping on a socket, > applications need to

Re: [RESEND PATCH net-next 00/13] Enhance stmmac driver to support GMAC4.x IP

From: Alexandre TORGUE Date: Fri, 1 Apr 2016 11:37:24 +0200 > This is a subset of patch to enhance current stmmac driver to support > new GMAC4.x chips. New set of callbacks is defined to support this new > family: descriptors, dma, core. Series applied, thanks.

Re: [PATCH v2 net-next] net: hns: add support of pause frame ctrl for HNS V2

From: Yisen Zhuang Date: Thu, 31 Mar 2016 21:00:09 +0800 > From: Lisheng > > The patch adds support of pause ctrl for HNS V2, and this feature is lost > by HNS V1: >1) service ports can disable rx pause frame, >2) debug ports can

Re: [PATCH] netlink: use nla_get_in_addr and nla_put_in_addr for ipv4 address

From: Haishuang Yan Date: Thu, 31 Mar 2016 18:21:38 +0800 > Since nla_get_in_addr and nla_put_in_addr were implemented, > so use them appropriately. > > Signed-off-by: Haishuang Yan Applied, thank you.

Re: [PATCH v2 net-next] tcp: remove cwnd moderation after recovery

From: Yuchung Cheng Date: Wed, 30 Mar 2016 14:54:20 -0700 > For non-SACK connections, cwnd is lowered to inflight plus 3 packets > when the recovery ends. This is an optional feature in the NewReno > RFC 2582 to reduce the potential burst when cwnd is "re-opened" > after

Re: [RFC PATCH 0/5] Add driver bpf hook for early packet drop

On Sat, Apr 2, 2016 at 2:41 PM, Johannes Berg wrote: > On Fri, 2016-04-01 at 18:21 -0700, Brenden Blanco wrote: >> This patch set introduces new infrastructure for programmatically >> processing packets in the earliest stages of rx, as part of an effort >> others are

Re: bridge/brctl/ip

On 04/02/2016 09:26 PM, Bert Vermeulen wrote: > Hi all, > > I'm wondering about the current userspace toolset to control bridging in > the Linux kernel. As far as I can determine, functionality is a bit > scattered right now between the iproute2 (ip, bridge) and bridge-utils > (brctl) tools: > >

Re: bridge/brctl/ip

On Sat, Apr 02, 2016 at 09:26:55PM +0200, Bert Vermeulen wrote: > Hi all, > > I'm wondering about the current userspace toolset to control bridging in > the Linux kernel. As far as I can determine, functionality is a bit > scattered right now between the iproute2 (ip, bridge) and bridge-utils >

Re: net: memory leak due to CLONE_NEWNET

On Sat, Apr 2, 2016 at 6:55 AM, Dmitry Vyukov wrote: > Hello, > > The following program leads to memory leaks in: > > unreferenced object 0x88005c10d208 (size 96): > comm "a.out", pid 10753, jiffies 4296778619 (age 43.118s) > hex dump (first 32 bytes): > e8 31 85

Re: [net PATCH 2/2] ipv4/GRO: Make GRO conform to RFC 6864

On 04/01/2016 07:21 PM, Eric Dumazet wrote: On Fri, 2016-04-01 at 22:16 -0400, David Miller wrote: From: Alexander Duyck Date: Fri, 1 Apr 2016 12:58:41 -0700 RFC 6864 is pretty explicit about this, IPv4 ID used only for fragmentation.

bridge/brctl/ip

Hi all, I'm wondering about the current userspace toolset to control bridging in the Linux kernel. As far as I can determine, functionality is a bit scattered right now between the iproute2 (ip, bridge) and bridge-utils (brctl) tools: - creating/deleting bridges: ip or brctl - adding/deleting

[PATCH v3 -next] net/core/dev: Warn on a too-short GRO frame

From: Aaron Conole When signaling that a GRO frame is ready to be processed, the network stack correctly checks length and aborts processing when a frame is less than 14 bytes. However, such a condition is really indicative of a broken driver, and should be loudly signaled,

Re: [RFC PATCH 4/5] mlx4: add support for fast rx drop bpf program

On Fri, 2016-04-01 at 18:21 -0700, Brenden Blanco wrote: > +static int mlx4_bpf_set(struct net_device *dev, int fd) > +{ [...] > + if (prog->type != BPF_PROG_TYPE_PHYS_DEV) { > + bpf_prog_put(prog); > + return -EINVAL; > + } > +

Re: [RFC PATCH 0/5] Add driver bpf hook for early packet drop

On Fri, 2016-04-01 at 18:21 -0700, Brenden Blanco wrote: > This patch set introduces new infrastructure for programmatically > processing packets in the earliest stages of rx, as part of an effort > others are calling Express Data Path (XDP) [1]. Start this effort by > introducing a new bpf

Re: Question on rhashtable in worst-case scenario.

On Sat, 2016-04-02 at 09:46 +0800, Herbert Xu wrote: > On Fri, Apr 01, 2016 at 11:34:10PM +0200, Johannes Berg wrote: > > > > > > I was thinking about that one - it's not obvious to me from the > > code > > how this "explicitly checking for dups" would be done or let's say > > how > > rhashtable

[PATCH v2] net: remove unimplemented RTNH_F_PERVASIVE

Linux 2.1.68 introduced RTNH_F_PERVASIVE, but it had no implementation and couldn't be enabled since the required config parameter wasn't in any Kconfig file (see commit d088dde7b196 ("ipv4: obsolete config in kernel source (IP_ROUTE_PERVASIVE)")). This commit removes all remaining references to

Re: [RFC PATCH 0/5] Add driver bpf hook for early packet drop

On Fri, Apr 1, 2016 at 9:21 PM, Brenden Blanco wrote: > This patch set introduces new infrastructure for programmatically > processing packets in the earliest stages of rx, as part of an effort > others are calling Express Data Path (XDP) [1]. Start this effort by >

Re: [RFC PATCH 1/5] bpf: add PHYS_DEV prog type for early driver filter

On Fri, Apr 1, 2016 at 9:21 PM, Brenden Blanco wrote: > Add a new bpf prog type that is intended to run in early stages of the > packet rx path. Only minimal packet metadata will be available, hence a new > context type, struct xdp_metadata, is exposed to userspace. So far

Re: [PATCH v2 net-next 01/11] net: add SOCK_RCU_FREE socket flag

On Fri, Apr 1, 2016 at 11:52 AM, Eric Dumazet wrote: > We want a generic way to insert an RCU grace period before socket > freeing for cases where RCU_SLAB_DESTROY_BY_RCU is adding too > much overhead. > > SLAB_DESTROY_BY_RCU strict rules force us to take a reference > on the

Re: [PATCH v2 net-next 02/11] udp: no longer use SLAB_DESTROY_BY_RCU

On Fri, Apr 1, 2016 at 11:52 AM, Eric Dumazet wrote: > Tom Herbert would like not touching UDP socket refcnt for encapsulated > traffic. For this to happen, we need to use normal RCU rules, with a grace > period before freeing a socket. UDP sockets are not short lived in the

Re: [PATCH] net: remove unimplemented RTNH_F_PERVASIVE

Hello. On 4/2/2016 11:43 AM, Quentin Armitage wrote: Linux 2.1.68 introduced RTNH_F_PERVASIVE, but it had no implementation and couldn't be enabled since the required config parameter wasn't in any Kconfig file (see commit d088dde7b). scripts/checkpatch.pl now enforces certain commit

net: memory leak due to CLONE_NEWNET

Hello, The following program leads to memory leaks in: unreferenced object 0x88005c10d208 (size 96): comm "a.out", pid 10753, jiffies 4296778619 (age 43.118s) hex dump (first 32 bytes): e8 31 85 2d 00 88 ff ff 0f 00 00 00 00 00 00 00 .1.- 00 00 00 00 ad 4e ad de ff

[PATCH] net: remove unimplemented RTNH_F_PERVASIVE

Linux 2.1.68 introduced RTNH_F_PERVASIVE, but it had no implementation and couldn't be enabled since the required config parameter wasn't in any Kconfig file (see commit d088dde7b). This commit removes all remaining references to RTNH_F_PERVASIVE. Although this will cause userspace applications

Re: [RFC PATCH 4/5] mlx4: add support for fast rx drop bpf program

First of all, I'm very happy to see people start working on this! Thanks you Brenden! On Fri, 1 Apr 2016 18:21:57 -0700 Brenden Blanco wrote: > Add support for the BPF_PROG_TYPE_PHYS_DEV hook in mlx4 driver. Since > bpf programs require a skb context to navigate the

Re: [net PATCH 2/2] ipv4/GRO: Make GRO conform to RFC 6864

On Fri, Apr 1, 2016 at 7:16 PM, David Miller wrote: > From: Alexander Duyck > Date: Fri, 1 Apr 2016 12:58:41 -0700 > >> RFC 6864 is pretty explicit about this, IPv4 ID used only for >> fragmentation. https://tools.ietf.org/html/rfc6864#section-4.1