similar to: 4.20-rc6: WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect

On Thu, Dec 20, 2018 at 9:16 AM Ido Schimmel <idosch at idosch.org> wrote: > > On Thu, Dec 20, 2018 at 09:04:25AM -0500, Willem de Bruijn wrote: > > On Thu, Dec 20, 2018 at 6:15 AM Ido Schimmel <idosch at idosch.org> wrote: > > > > > > +Willem > > > > > > On Thu, Dec 20, 2018 at 08:45:40AM +0100, Christian Borntraeger wrote: > >

On 20.12.2018 10:12, Ido Schimmel wrote: > +Willem > > On Thu, Dec 20, 2018 at 08:45:40AM +0100, Christian Borntraeger wrote: >> Folks, >> >> I got this warning today. I cant tell when and why this happened, so I do not know yet how to reproduce. >> Maybe someone has a quick idea. >> >> [85109.572032] WARNING: CPU: 30 PID: 197360 at

On 20.12.2018 18:23, Willem de Bruijn wrote: > On Thu, Dec 20, 2018 at 11:17 AM Ido Schimmel <idosch at idosch.org> wrote: >> >> On Thu, Dec 20, 2018 at 03:09:22PM +0100, Christian Borntraeger wrote: >>> On 20.12.2018 10:12, Ido Schimmel wrote: >>>> +Willem >>>> >>>> On Thu, Dec 20, 2018 at 08:45:40AM +0100, Christian Borntraeger

On Thu, Dec 20, 2018 at 11:17 AM Ido Schimmel <idosch at idosch.org> wrote: > > On Thu, Dec 20, 2018 at 03:09:22PM +0100, Christian Borntraeger wrote: > > On 20.12.2018 10:12, Ido Schimmel wrote: > > > +Willem > > > > > > On Thu, Dec 20, 2018 at 08:45:40AM +0100, Christian Borntraeger wrote: > > >> Folks, > > >> > >

On Thu, Dec 20, 2018 at 11:17 AM Ido Schimmel <idosch at idosch.org> wrote: > > On Thu, Dec 20, 2018 at 03:09:22PM +0100, Christian Borntraeger wrote: > > On 20.12.2018 10:12, Ido Schimmel wrote: > > > +Willem > > > > > > On Thu, Dec 20, 2018 at 08:45:40AM +0100, Christian Borntraeger wrote: > > >> Folks, > > >> > >

Folks, I got this warning today. I cant tell when and why this happened, so I do not know yet how to reproduce. Maybe someone has a quick idea. [85109.572032] WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect+0x1f0/0x1318 [85109.572036] Modules linked in: vhost_net vhost macvtap macvlan tap vfio_ap vfio_mdev mdev vfio_iommu_type1 vfio kvm xt_CHECKSUM ipt_MASQUERADE

This patch introduces to a new tun/tap specific msg_control: #define TUN_MSG_UBUF 1 #define TUN_MSG_PTR 2 struct tun_msg_ctl { int type; void *ptr; }; This allows us to pass different kinds of msg_control through sendmsg(). The first supported type is ubuf (TUN_MSG_UBUF) which will be used by the existed vhost_net zerocopy code. The second is XDP buff, which allows vhost_net to

On Thu, Sep 06, 2018 at 12:05:23PM +0800, Jason Wang wrote: > This patch introduces to a new tun/tap specific msg_control: > > #define TUN_MSG_UBUF 1 > #define TUN_MSG_PTR 2 > struct tun_msg_ctl { > int type; > void *ptr; > }; > > This allows us to pass different kinds of msg_control through > sendmsg(). The first supported type is ubuf

This patch implement TUN_MSG_PTR msg_control type. This type allows the caller to pass an array of XDP buffs to tuntap through ptr field of the tun_msg_control. Tap will build skb through those XDP buffers. This will avoid lots of indirect calls thus improves the icache utilization and allows to do XDP batched flushing when doing XDP redirection. Signed-off-by: Jason Wang <jasowang at

On Thu, Sep 06, 2018 at 12:05:25PM +0800, Jason Wang wrote: > This patch implement TUN_MSG_PTR msg_control type. This type allows > the caller to pass an array of XDP buffs to tuntap through ptr field > of the tun_msg_control. Tap will build skb through those XDP buffers. > > This will avoid lots of indirect calls thus improves the icache > utilization and allows to do XDP

On Fri, May 19, 2023 at 02:52:18PM -0700, Jakub Kicinski wrote: > On Fri, 19 May 2023 16:51:48 +0300 Ido Schimmel wrote: > > diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c > > index fc17b9fd93e6..274e55455b15 100644 > > --- a/net/bridge/br_input.c > > +++ b/net/bridge/br_input.c > > @@ -46,6 +46,8 @@ static int br_pass_frame_up(struct sk_buff *skb) >

? 2023/2/20 21:56, Jiri Pirko ??: > Mon, Feb 20, 2023 at 01:55:33PM CET, mst at redhat.com wrote: >> On Mon, Feb 20, 2023 at 09:35:00AM +0100, Jiri Pirko wrote: >>> Fri, Feb 17, 2023 at 02:47:36PM CET, mst at redhat.com wrote: >>>> On Fri, Feb 17, 2023 at 01:53:55PM +0100, Jiri Pirko wrote: >>>>> Fri, Feb 17, 2023 at 01:22:01PM CET, mst at redhat.com

On Tue, 2023-05-23 at 11:10 +0300, Ido Schimmel wrote: > On Fri, May 19, 2023 at 02:52:18PM -0700, Jakub Kicinski wrote: > > On Fri, 19 May 2023 16:51:48 +0300 Ido Schimmel wrote: > > > diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c > > > index fc17b9fd93e6..274e55455b15 100644 > > > --- a/net/bridge/br_input.c > > > +++

tl;dr ===== This patchset adds a single bit to the skb to indicate that a packet encountered a layer 2 miss in the bridge and extends flower to match on this metadata. This is required for non-DF (Designated Forwarder) filtering in EVPN multi-homing which prevents decapsulated BUM packets from being forwarded multiple times to the same multi-homed host. Background ========== In a typical EVPN

tl;dr ===== This patchset adds a single bit to the skb to indicate that a packet encountered a layer 2 miss in the bridge and extends flower to match on this metadata. This is required for non-DF (Designated Forwarder) filtering in EVPN multi-homing which prevents decapsulated BUM packets from being forwarded multiple times to the same multi-homed host. Background ========== In a typical EVPN

Jiri Pirko wrote: > Tue, Feb 21, 2023 at 05:12:33PM CET, willemdebruijn.kernel at gmail.com wrote: > >Jiri Pirko wrote: > >> Tue, Feb 21, 2023 at 04:11:53PM CET, willemdebruijn.kernel at gmail.com wrote: > >> >Jiri Pirko wrote: > >> >> From: Jiri Pirko <jiri at nvidia.com> > >> >> > >> >> Virtio spec introduced a

Make any attributes newly-added to br_port_policy or vlan_tunnel_policy parsed strictly, to prevent userspace from passing garbage. Note that this patchset only touches the former policy. The latter was adjusted for completeness' sake. There do not appear to be other _deprecated calls with non-NULL policies. Suggested-by: Ido Schimmel <idosch at nvidia.com> Signed-off-by: Petr Machata

Hi all: This series tries to batch submitting packets to underlayer socket through msg_control during sendmsg(). This is done by: 1) Doing userspace copy inside vhost_net 2) Build XDP buff 3) Batch at most 64 (VHOST_NET_BATCH) XDP buffs and submit them once through msg_control during sendmsg(). 4) Underlayer sockets can use XDP buffs directly when XDP is enalbed, or build skb based on XDP

On Tue, Mar 28, 2023 at 19:40, Ido Schimmel <idosch at nvidia.com> wrote: > On Sun, Mar 26, 2023 at 05:41:06PM +0200, Hans Schultz wrote: >> On Mon, Mar 20, 2023 at 10:44, Ido Schimmel <idosch at nvidia.com> wrote: >> >> + $MZ $swp1 -c 1 -p 128 -t udp "sp=54321,dp=12345" \ >> >> + -a $mac -b `mac_get $h2` -A 192.0.2.1 -B 192.0.2.2 -q >>

On Tue, Mar 28, 2023 at 19:40, Ido Schimmel <idosch at nvidia.com> wrote: > On Sun, Mar 26, 2023 at 05:41:06PM +0200, Hans Schultz wrote: >> On Mon, Mar 20, 2023 at 10:44, Ido Schimmel <idosch at nvidia.com> wrote: >> >> + $MZ $swp1 -c 1 -p 128 -t udp "sp=54321,dp=12345" \ >> >> + -a $mac -b `mac_get $h2` -A 192.0.2.1 -B 192.0.2.2 -q >>