[ 54.304576] eth0: hw csum failure

Hi there, I am getting the following in dmesg upon startup from [ 54.304576] eth0: hw csum failure [ 54.304610] CPU: 0 PID: 0 Comm: swapper Not tainted 4.17.0+ #3 [ 54.304616] Call Trace: [ 54.304633] [dffedbd0] [c069d178] __skb_checksum_complete+0xf0/0x108 (unreliable) [ 54.304653]

Re: [PATCH v6 net] stmmac: strip all VLAN tag types when kernel 802.1Q support is selected

From: Elad Nachman Date: Fri, 8 Jun 2018 12:19:29 +0300 > stmmac reception handler calls stmmac_rx_vlan() to strip the vlan before > calling napi_gro_receive(). > > The function assumes VLAN tagged frames are always tagged with > 802.1Q protocol, and assigns ETH_P_8021Q to the skb by

[PATCH RFC v2 3/9] veth: Avoid drops by oversized packets when XDP is enabled

From: Toshiaki Makita All oversized packets including GSO packets are dropped if XDP is enabled on receiver side, so don't send such packets from peer. Drop TSO and SCTP fragmentation features so that veth devices themselves segment packets with XDP enabled. Also cap MTU accordingly.

[PATCH RFC v2 8/9] veth: Support per queue XDP ring

From: Toshiaki Makita Move XDP and napi related fields in veth_priv to newly created veth_rq structure. When xdp_frames are enqueued from ndo_xdp_xmit and XDP_TX, rxq is selected by current cpu. When skbs are enqueued from the peer device, rxq is determined by its peer's txq. In this way we can

[PATCH RFC v2 1/9] net: Export skb_headers_offset_update

From: Toshiaki Makita v2: - Drop skb_copy_header part because it has already been exported now. Signed-off-by: Toshiaki Makita --- include/linux/skbuff.h | 1 + net/core/skbuff.c | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/include/linux/skbuff.h

[PATCH RFC v2 7/9] veth: Add XDP TX and REDIRECT

From: Toshiaki Makita This allows further redirection of xdp_frames like NIC -> veth--veth -> veth--veth (XDP) (XDP) (XDP) The intermediate XDP, redirecting packets from NIC to the other veth, reuses xdp_mem_info from NIC so that page recycling of the NIC works on the

Re: [Patch net] socket: close race condition between sock_close() and sockfs_setattr()

From: Cong Wang Date: Thu, 7 Jun 2018 13:39:49 -0700 > fchownat() doesn't even hold refcnt of fd until it figures out > fd is really needed (otherwise is ignored) and releases it after > it resolves the path. This means sock_close() could race with > sockfs_setattr(), which leads to a NULL

Re: netdevice notifier and device private data

Hi, On Sat, Jun 09, 2018 at 03:01:18PM -0400, Michael Richardson wrote: > > Alexander Aring wrote: > > Futhermore user space programs e.g. radvd will do 6lowpan specific > > handling on 6lowpan dev->type, it will not work either on tun > > devices. > > > I know that wpantund

[PATCH RFC v2 6/9] xdp: Add a flag for disabling napi_direct of xdp_return_frame in xdp_mem_info

From: Toshiaki Makita We need some mechanism to disable napi_direct on calling xdp_return_frame_rx_napi() from some context. When veth gets support of XDP_REDIRECT, it will redirects packets which are redirected from other devices. On redirection veth will reuse xdp_mem_info of the redirection

[PATCH RFC v2 5/9] veth: Add ndo_xdp_xmit

From: Toshiaki Makita This allows NIC's XDP to redirect packets to veth. The destination veth device enqueues redirected packets to the napi ring of its peer, then they are processed by XDP on its peer veth device. This can be thought as calling another XDP program by XDP program using REDIRECT,

[PATCH RFC v2 2/9] veth: Add driver XDP

From: Toshiaki Makita This is basic implementation of veth driver XDP. Incoming packets are sent from the peer veth device in the form of skb, so this is generally doing the same thing as generic XDP. This itself is not so useful, but a starting point to implement other useful veth XDP

[PATCH RFC v2 4/9] veth: Add another napi ring for ndo_xdp_xmit and handle xdp_frames

From: Toshiaki Makita This is preparation for XDP TX and ndo_xdp_xmit. Add another napi ring and handle redirected xdp_frames through it. v2: - Use another ring instead of using flag to differentiate skb and xdp_frame. This approach makes bulk skb transmit possible in veth_xmit later. -

[PATCH RFC v2 9/9] veth: Bulk skb xmit for XDP path

From: Toshiaki Makita Aquire txq lock instead of rxq ptr_ring lock so we avoid per-packet lock when skb->xmit_more is true. We ensure that rxqs are always not less than txqs and txq to rxq is one to one mapping, so we can completely remove rxq side lock. Since we removed rxq side lock, this

[PATCH RFC v2 0/9] veth: Driver XDP

From: Toshiaki Makita This patch set introduces driver XDP for veth. Basically this is used in conjunction with redirect action of another XDP program. NIC ---> veth===veth (XDP) (redirect)(XDP) In this case xdp_frame can be forwarded to the peer veth without modification,

Re: [Patch net] socket: close race condition between sock_close() and sockfs_setattr()

On Sun, Jun 10, 2018 at 12:27 PM, David Miller wrote: > I'm applying this for now, it is at least a step towards fixing > all of these issues. > > If it is really offensive, I can revert, just tell me. Thanks, David! Unless there is something fundamentally broken, there is no reason to revert

Re: netdevice notifier and device private data

Alexander Aring wrote: >> It totally seems like broken behaviour. Maybe it's not even >> intentional. Maybe they are just foobar. > They simple don't know what they doing... somebody thought 6LoWPAN need > to be 6LoWPAN, but they actually don't use the 6LoWPAN handling inside

[PATCH net-next] vlan: implement vlan id and protocol changes

From: "Charles (Chas) Williams" vlan_changelink silently ignores attempts to change the vlan id or protocol id of an existing vlan interface. Implement by adding the new vlan id and protocol to the interface's vlan group and then removing the old vlan id and protocol from the vlan group.

Re: [PATCH] net: phy: dp83822: use BMCR_ANENABLE instead of BMSR_ANEGCAPABLE for DP83620

From: Alvaro Gamez Machado Date: Fri, 8 Jun 2018 12:23:39 +0200 > DP83620 register set is compatible with the DP83848, but it also supports > 100base-FX. When the hardware is configured such as that fiber mode is > enabled, autonegotiation is not possible. > > The chip, however, doesn't expose

[PATCH net] ipv6: allow PMTU exceptions to local routes

IPVS setups with local client and remote tunnel server need to create exception for the local virtual IP. What we do is to change PMTU from 64KB (on "lo") to 1460 in the common case. Suggested-by: Martin KaFai Lau Fixes: 45e4fd26683c ("ipv6: Only create RTF_CACHE routes after encountering pmtu

Re: [PATCH net-next] vlan: implement vlan id and protocol changes

Hi Charles, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on net-next/master] url: https://github.com/0day-ci/linux/commits/Chas-Williams/vlan-implement-vlan-id-and-protocol-changes/20180611-072123 config: parisc-c3000_defconfig (attached as .config)

Re: [PATCH v6 net] stmmac: strip all VLAN tag types when kernel 802.1Q support is selected

On 2018/06/11 4:29, David Miller wrote: > From: Elad Nachman > Date: Fri, 8 Jun 2018 12:19:29 +0300 > >> stmmac reception handler calls stmmac_rx_vlan() to strip the vlan before >> calling napi_gro_receive(). >> >> The function assumes VLAN tagged frames are always tagged with >> 802.1Q