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
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 protoco
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)
compile
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.
Signed
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 e
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 it
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
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 hard-codi
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 point
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] [df
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 b/include/linux/
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 desti
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.
Signed-off
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
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 so
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,
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 features
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.
- Clea
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 chan
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, so
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 fro
21 matches
Mail list logo