ue on the first initialization, but more because 0+ for success and
-errno for failure is a more common.
Queued with this change, thanks.
(Keith, I haven't forgotten about AVX by the way).
Paolo
e, but the following
patches looks like net-next material. Any special reason to bundle them
together?
Also, please explicitly include the the target tree in the subj on next
submissions, thanks!
Paolo
this should be squashed in a previous patch,
likely "virtio_net: xsk: bind/unbind xsk for rx"
Thanks,
Paolo
> + struct xdp_buff *xdp;
> + u32 len;
> +
> + while (num_buf-- > 1) {
Why do you skip the last buffer? I thought it should be dropped, too?!?
Thanks!
Paolo
se _do not_ repost just for the above, but please include such
changes if you should repost for other reasons.
Also try to include a detailed changelog in each patch after the tag
area and a '---' separator, it will simplify the review process.
Thanks,
Paolo
t+0x3a2/0x8a0
> ? lock_release+0x72/0x140
> ? do_user_addr_fault+0x3a7/0x8a0
> __x64_sys_sendto+0x29/0x30
> do_syscall_64+0x78/0x180
> entry_SYSCALL_64_after_hwframe+0x76/0x7e
>
> Fixes: 4d4ac2ececd3 ("virtio_net: Add a lock for per queue RX coalesce")
> Signed-off-by: Heng Qi
This would have deserved a changelog after the commit message.
The patch LGTM (for obvious reasons ;), but it deserves an explicit ack
from Jason and/or Michael
Cheers,
Paolo
On Tue, May 28, 2024 at 5:53 PM Stefano Garzarella wrote:
>
> On Tue, May 28, 2024 at 05:49:32PM GMT, Paolo Bonzini wrote:
> >On Tue, May 28, 2024 at 5:41 PM Stefano Garzarella
> >wrote:
> >> >I think it's either that or implementing virtio-vsock in userspace
>
> For in this case AF_VSOCK can't be used in the host, right?
> So it's similar to vhost-user-vsock.
Not sure if I understand but in this case QEMU knows which CIDs are
forwarded to the host (either listen on vsock and connect to the host,
or vice versa), so there is no kernel and no VMADDR_FLAG_TO_HOST
involved.
Paolo
t's either that or implementing virtio-vsock in userspace
(https://lore.kernel.org/qemu-devel/30baeb56-64d2-4ea3-8e53-6a5c50999...@redhat.com/,
search for "To connect host<->guest").
Paolo
On Tue, 2024-05-28 at 11:06 +0800, Heng Qi wrote:
> On Mon, 27 May 2024 12:42:43 +0200, Paolo Abeni wrote:
> > On Thu, 2024-05-23 at 15:46 +0800, Heng Qi wrote:
> > > This reverts commit 4d4ac2ececd3c42a08dd32a6e3a4aaf25f7efe44.
> > >
> > > When the following
nstead re-factoring
virtnet_send_rx_notf_coal_cmds() to avoid acquiring all the mutex in
sequence?
Thanks!
Paolo
On Mon, 2024-05-20 at 09:03 +0800, Jason Wang wrote:
> This patch synchronize operstate with admin state per RFC2863.
>
> This is done by trying to toggle the carrier upon open/close and
> synchronize with the config change work. This allows propagate status
> correctly to stacked devices like:
>
patches landing on virtio_net on net-next, I guess
there will be some conflict while pushing to Linux (but I haven't
double check yet!)
Perhaps you could provide a stable git branch so that both vhost and
netdev could pull this set?
Thanks!
Paolo
only process the provided queue in
> virtnet_dim_work
> - New patch to lock per queue rx coalescing structure.
I had only some minor comments, possibly overall worth another
iteration.
More importantly, this deserves an explicit ack from the virtio crew.
@Jason, @Michael: could you please have a look?
Thanks!
Paolo
sabled.
Minor nit: the above comment looks confusing/mangled to me ?!?
will take the lock and will not update settings...
Thanks,
Paolo
;status == VIRTIO_NET_OK;
> }
>
> @@ -4818,8 +4824,10 @@ static int virtnet_probe(struct virtio_device *vdev)
> virtio_has_feature(vdev, VIRTIO_F_VERSION_1))
> vi->any_header_sg = true;
>
> - if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
> + if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ)) {
> vi->has_cvq = true;
> + mutex_init(&vi->cvq_lock);
I'm wondering if syzkaller will be able to touch the lock in some
unexpected path? possibly worth always initializing it?
Thanks,
Paolo
On Tue, 2024-04-23 at 06:57 +0300, Daniel Jurgens wrote:
> Allocate memory for the data when it's used. Ideally the could be on the
Minor nit: 'buffer' or 'struct' is missing here
No need to repost just for this.
Thank,
Paolo
On Thu, 2024-04-18 at 15:38 +, Dan Jurgens wrote:
> > From: Paolo Abeni
> > Sent: Thursday, April 18, 2024 5:57 AM
> > On Thu, 2024-04-18 at 15:36 +0800, Heng Qi wrote:
> > >
> > > 在 2024/4/18 下午2:42, Jason Wang 写道:
> > > > On Wed, A
t I need a little time to test, this is close to fast. So could the
> topic about cond_resched +
> spin lock or mutex lock be wait?
The big problem is that until the cond_resched() is there, replacing
the mutex with a spinlock can/will lead to scheduling while atomic
splats. We can't intentionally introduce such scenario.
Side note: the compiler apparently does not like guard() construct,
leading to new warning, here and in later patches. I'm unsure if the
code simplification is worthy.
Cheers,
Paolo
nux/virtio_vsock.h
> +++ b/include/linux/virtio_vsock.h
> @@ -134,6 +134,8 @@ struct virtio_vsock_sock {
> u32 peer_fwd_cnt;
> u32 peer_buf_alloc;
>
> + atomic_t bytes_unsent;
This will add 2 atomic operations per packet, possibly on contended
cachelines. Have you considered leveraging the existing transport-level
lock to protect the counter updates?
Thanks
Paolo
el.org/
I really think a different solution is needed. What about moving
virtnet_send_command() under protection of a new mutex?
I understand it will complicate future hardening works around cvq, but
really rtnl_trylock()/ is bad for the whole system.
Cheers,
Paolo
>
> > > net-next is closed. Please resubmit next week.
> >
> >
> > For review.
>
> RFC, or wait.
@Xuan, please note that you received exactly the same feedback on your
previous submission, a few days ago. While I do understand the legit
interest in reviews, ignoring explicit feedback tend to bring no
feedback at all.
Paolo
On Thu, 2024-03-14 at 16:54 +0800, Xuan Zhuo wrote:
> As the spec:
>
> https://github.com/oasis-tcs/virtio-spec/commit/42f389989823039724f95bbbd243291ab0064f82
>
> The virtio net supports to get device stats.
>
> Please review.
>
> Thanks.
>
>
> v4:
> 1. Support per-queue statistics API
>
On Tue, 2024-01-16 at 17:42 +0800, Xuan Zhuo wrote:
> This is the third part of virtio-net support AF_XDP zero copy.
>
> The whole patch set
> http://lore.kernel.org/all/20231229073108.57778-1-xuanz...@linux.alibaba.com
>
> ## AF_XDP
>
> XDP socket(AF_XDP) is an excellent bypass kernel
On Tue, 2024-01-16 at 14:28 +0800, Xuan Zhuo wrote:
> This is first part of virtio-net support AF_XDP zero copy.
For future submissions, unless explcitly requested otherwise, please
wait for a series being processed before posting the follow-ups.
Otherwise any change requested to earlier patches c
i->cvq, &tmp) &&
> -!virtqueue_is_broken(vi->cvq))
> +!virtqueue_is_broken(vi->cvq)) {
> + if (timeout)
> + timeout--;
This is not really a timeout, just a loop counter. 200 iterations could
be a very short time on reasonable H/W. I guess this avoid the soft
lockup, but possibly (likely?) breaks the functionality when we need to
loop for some non negligible time.
I fear we need a more complex solution, as mentioned by Micheal in the
thread you quoted.
Cheers,
Paolo
(), without flushing the work
- virtnet_remove() calls flush_work() after unregister_netdev(),
outside the rtnl lock
Should prevent both the deadlock and the UaF.
Side note: for this specific case any functional test with a
CONFIG_LOCKDEP enabled build should suffice to catch the deadlock
scenario above.
Cheers,
Paolo
here, what prevents it from completing
after the following unregister/free netdev?
It looks like you want need to call cancel_work_sync here?
Additionally the later remove_vq_common() will needless call
cancel_work() again; possibly is better to consolidate a single (sync)
call there.
Cheers,
Paolo
hile true
> do
> ethtool -G ens4 rx 128
> ethtool -G ens4 rx 256
> free -m
> done
>
> Fixes: 295525e29a5b ("virtio_net: merge dma operations when filling mergeable
> buffers")
> Signed-off-by: Xuan Zhuo
@Micheal, @Jason: this fix LGTM, but I guess it deserve an explicit ack
from you before merging, thanks!
Paolo
Quoting Stephen Hemminger :
On Thu, 15 Apr 2021 20:06:43 +0200
Paolo Lungaroni wrote:
+ if (is_json_context())
+ open_json_object("stats64");
+
+ if (tb[SEG6_LOCAL_CNT_PACKETS]) {
+ packets = rta_getattr_u64(tb[SEG6_LOCAL_C
if (!rcu_access_pointer(rq->napi))
> goto out;
>
> max_len = rcv->mtu + rcv->hard_header_len + VLAN_HLEN;
Acked-by: Paolo Abeni
Thanks for the quick turn-around!
On Fri, 2021-04-16 at 17:29 +0200, Toke Høiland-Jørgensen wrote:
> Paolo Abeni writes:
>
> > On Fri, 2021-04-09 at 16:58 +0200, Toke Høiland-Jørgensen wrote:
> > > Paolo Abeni writes:
> > >
> > > > Currently the veth device has the GRO feature bit
Borntraeger
Signed-off-by: Masahiro Yamada
looks better.
Tested-by: Christian Borntraeger
Thank you very much Masahiro, this look great.
Paolo
l action End packets 0 bytes 0 errors 0 dev eth0
[1] https://www.rfc-editor.org/rfc/rfc8986.html#name-counters
Signed-off-by: Andrea Mayer
Signed-off-by: Paolo Lungaroni
---
include/uapi/linux/seg6_local.h | 30 +
ip/iproute_lwtunnel.c | 80 +
On 15/04/21 10:04, Masahiro Yamada wrote:
On Thu, Apr 15, 2021 at 4:40 PM Paolo Bonzini wrote:
I think it would make sense to add try-run, cc-option and
.DELETE_ON_ERROR to tools/build/Build.include?
To be safe, I just copy-pasted what the makefiles need.
If someone wants to refactor the
I think it would make sense to add try-run, cc-option and
.DELETE_ON_ERROR to tools/build/Build.include?
Paolo
Link:
https://lore.kernel.org/lkml/86dadf33-70f7-a5ac-cb8c-64966d2f4...@linux.ibm.com/
Fixes: d9f4ff50d2aa ("kbuild: spilt cc-option and friends to
scripts/Makefile.compiler")
and the
tunnel decapsulation will call pskb_expand_head().
Fixes: 1ddc3229ad3c ("skbuff: remove some unnecessary operation in
skb_segment_list()")
Signed-off-by: Paolo Abeni
---
net/core/skbuff.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --
vide the decoded the stack trace? Something
alike the following will do:
cat | ./scripts/decode_stacktrace.sh
Even more importantly:
threaded napi is implemented with the merge
commit adbb4fb028452b1b0488a1a7b66ab856cdf20715, which landed into the
vanilla tree since v5.12.rc1 and is not backported to 5.11.x. What
kernel are you really using?
Thanks,
Paolo
ain napi_thread_poll() loop clear the SCHED bit
Reported-by: Jakub Kicinski
Fixes: 29863d41bb6e ("net: implement threaded-able napi poll loop support")
Signed-off-by: Paolo Abeni
---
net/core/dev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/cor
On Fri, 2021-04-09 at 16:58 +0200, Toke Høiland-Jørgensen wrote:
> Paolo Abeni writes:
>
> > Currently the veth device has the GRO feature bit set, even if
> > no GRO aggregation is possible with the default configuration,
> > as the veth device does not
hello,
On Fri, 2021-04-09 at 16:57 +0200, Toke Høiland-Jørgensen wrote:
> Paolo Abeni writes:
>
> > After the previous patch, when enabling GRO, locally generated
> > TCP traffic experiences some measurable overhead, as it traverses
> > the GRO engine without a
Add some basic veth tests, that verify the expected flags and
aggregation with different setups (default, xdp, etc...)
Signed-off-by: Paolo Abeni
---
tools/testing/selftests/net/Makefile | 1 +
tools/testing/selftests/net/veth.sh | 177 +++
2 files changed, 178
is enabled
on a veth peer.
Only skbs that are eligible for aggregation enter the GRO layer,
the others will go through the traditional receive path.
Signed-off-by: Paolo Abeni
---
drivers/net/veth.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a
id the problem fixed with commit 4bf9ffa0fb57 ("veth:
Orphan skb before GRO")
Signed-off-by: Paolo Abeni
---
drivers/net/veth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 91b73db37555b..ad36e7ed16134 100644
--- a/driver
: Paolo Abeni
---
drivers/net/veth.c | 129 -
1 file changed, 116 insertions(+), 13 deletions(-)
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index ad36e7ed16134..ca44e82d1edeb 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -57,6
overhead for TCP traffic: some heuristic ensures
that TCP will not go through the additional NAPI/GRO layer.
Some self-tests are added to check the expected behavior in
the default configuration, with XDP and with plain GRO enabled.
Paolo Abeni (4):
veth: use skb_orphan_partial instead of skb_o
On Wed, 2021-04-07 at 11:13 -0700, Jakub Kicinski wrote:
> On Wed, 07 Apr 2021 16:54:29 +0200 Paolo Abeni wrote:
> > > > I think in the above example even the normal processing will be
> > > > fooled?!? e.g. even without the napi_disable(), napi_thread_wait() will
> &
l action End packets 0 bytes 0 errors 0 dev eth0
[1] https://www.rfc-editor.org/rfc/rfc8986.html#name-counters
Signed-off-by: Paolo Lungaroni
Signed-off-by: Andrea Mayer
---
include/uapi/linux/seg6_local.h | 8
ip/iproute_lwtunnel.c | 32 +++-
Hello,
I'm sorry for the lag,
On Thu, 2021-04-01 at 16:44 -0700, Jakub Kicinski wrote:
> On Thu, 01 Apr 2021 11:55:45 +0200 Paolo Abeni wrote:
> > On Wed, 2021-03-31 at 18:41 -0700, Jakub Kicinski wrote:
> > > On Thu, 1 Apr 2021 00:46:18 +0200 Paolo Abeni wrote:
>
This change reverts commit ad98dd37051e ("mptcp: provide subflow aware
release function"). The latter introduced a deadlock spotted by
syzkaller and is not needed anymore after the previous commit.
Fixes: ad98dd37051e ("mptcp: provide subflow aware release function")
Signed
){+.+.}-{0:0}, at: mptcp6_release+0x57/0x130
net/mptcp/protocol.c:3507
which lock already depends on the new lock.
Instead we can simply forbit any mcast-related setsockopt
Fixes: 717e79c867ca5 ("mptcp: Add setsockopt()/getsockopt() socket operations")
Signed-off-by: Paolo Abeni
---
implementation refactor
Paolo Abeni (2):
mptcp: forbit mcast-related sockopt on MPTCP sockets
mptcp: revert "mptcp: provide subflow aware release function"
net/mptcp/protocol.c | 100 ---
1 file changed, 47 insertions(+), 53 deletions(-)
--
2.26.2
On Wed, 2021-03-31 at 18:41 -0700, Jakub Kicinski wrote:
> On Thu, 1 Apr 2021 00:46:18 +0200 Paolo Abeni wrote:
> > I hit an hangup on napi_disable(), when the threaded
> > mode is enabled and the napi is under heavy traffic.
> >
> > If the relevant napi has been sch
loop support")
Signed-off-by: Paolo Abeni
---
net/core/dev.c | 8
1 file changed, 8 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index b4c67a5be606d..e2e716ba027b8 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -7059,6 +7059,14 @@ static int napi_thread_wait(struct n
subject for the patch. For me it clearly is a bug
> and not a new feature.
I have no strong opinion against that (sorry, I hoped that was clear in
my reply).
Please go ahead.
Thanks,
Paolo
ead of sort of open coding it (Eric)
- provide an helper for the ownership change (Eric)
Fixes: f6ba8d33cfbb ("netem: fix skb_orphan_partial()")
Suggested-by: Eric Dumazet
Signed-off-by: Paolo Abeni
---
include/net/sock.h | 9 +
net/core/sock.c| 12 +++-
2 file
On Tue, 2021-03-30 at 16:40 +0200, Eric Dumazet wrote:
> On Tue, Mar 30, 2021 at 4:39 PM Eric Dumazet wrote:
> > On Tue, Mar 30, 2021 at 4:25 PM Paolo Abeni wrote:
> > > Currently the mentioned helper can end-up freeing the socket wmem
> > > without waking-up any proce
after
releasing the memory, if the old skb destructor requires that.
Fixes: f6ba8d33cfbb ("netem: fix skb_orphan_partial()")
Signed-off-by: Paolo Abeni
---
net/core/sock.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/core/sock.c b/net/core/sock.c
index 0ed98f20448a2..7a3
Similar to the previous commit, let even geneve
passthrou the L4 GRO packets
Signed-off-by: Paolo Abeni
---
drivers/net/bareudp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/bareudp.c b/drivers/net/bareudp.c
index 7511bca9c15ed..edfad93e7b686 100644
--- a/drivers/net
aggregation
on top of UDP tunnel (vxlan)
v1 -> v2:
- hopefully clarify the commit message
- moved the overlay network ipv6 range into the 'documentation'
reserved range (Willem)
Signed-off-by: Paolo Abeni
---
tools/testing/selftests/net/Makefile | 1 +
tools/testing/
ueue_rcv_skb(),
as the UDP checksum has been validated by the GRO engine.
v2 -> v3:
- even more verbose commit message and comments
v1 -> v2:
- restrict the csum update to the packets strictly needing them
- hopefully clarify the commit message and code comments
Signed-off-by: Paolo Ab
Similar to the previous commit, let even geneve
passthrou the L4 GRO packets
Signed-off-by: Paolo Abeni
---
drivers/net/geneve.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 4ac0373326efd..5d7a2b1469f4c 100644
--- a/drivers/net/geneve.c
bitmask
(Willem)
- use only ipv6 addesses from test range in self-tests (Willem)
- hopefully clarified most individual patches commit messages
Paolo Abeni (8):
udp: fixup csum for GSO receive slow path
udp: skip L4 aggregation for UDP tunnel packets
udp: properly complete L4 GRO over U
()
accordingly.
UDP sockets enabling UDP_GRO stil keep accept_udp_fraglist
zeroed.
v1 -> v2:
- use 2 bits instead of a whole GSO bitmask (Willem)
Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
Signed-off-by: Paolo Abeni
---
include/linux/udp.h | 16 +---
n
udp_gro_complete() so that we can enter
the frag list path on the next round, for the inner header.
v1 -> v2:
- hopefully clarified the commit message
Reviewed-by: Willem de Bruijn
Signed-off-by: Paolo Abeni
---
net/ipv4/udp_offload.c | 8 +++-
net/ipv6/udp_offload.c | 3 ++-
2 fi
SO.")
Fixes: 36707061d6ba ("udp: allow forwarding of plain (non-fraglisted) UDP GRO
packets")
Reviewed-by: Willem de Bruijn
Signed-off-by: Paolo Abeni
---
net/ipv4/udp_offload.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/udp_offload.
.
v1 -> v2:
- updated to use the newly introduced UDP socket 'accept*' fields
Signed-off-by: Paolo Abeni
---
drivers/net/vxlan.c | 1 +
include/linux/udp.h | 6 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 7665817f3cb61..39ee130
On Mon, 2021-03-29 at 11:24 -0400, Willem de Bruijn wrote:
> On Mon, Mar 29, 2021 at 11:01 AM Paolo Abeni wrote:
> > On Mon, 2021-03-29 at 09:52 -0400, Willem de Bruijn wrote:
> > > > + if (skb->ip_summed == CHECKSUM_NONE && !skb->csum_valid)
> >
now touched twice.
The 'now' part confuses me. Nothing in this patch or this series
changes the processing of CHECKSUM_NONE UDP packets with no tunnel.
I do see checksum validation in the GRO engine for CHECKSUM_NONE UDP
packet prior to this series.
I *think* the checksum-and-copy optimization is lost
since 573e8fca255a27e3573b51f9b183d62641c47a3d.
Regards,
Paolo
On Mon, 2021-03-29 at 08:31 -0400, Willem de Bruijn wrote:
> On Mon, Mar 29, 2021 at 4:14 AM Paolo Abeni wrote:
> > On Fri, 2021-03-26 at 14:15 -0400, Willem de Bruijn wrote:
> > > On Thu, Mar 25, 2021 at 1:24 PM Paolo Abeni wrote:
> > > > Currently the UDP protocol
On Mon, 2021-03-29 at 08:28 -0400, Willem de Bruijn wrote:
> On Mon, Mar 29, 2021 at 7:26 AM Paolo Abeni wrote:
> > On Fri, 2021-03-26 at 14:30 -0400, Willem de Bruijn wrote:
> > > On Thu, Mar 25, 2021 at 1:24 PM Paolo Abeni wrote:
> > > > When UDP packets gene
On Fri, 2021-03-26 at 14:30 -0400, Willem de Bruijn wrote:
> On Thu, Mar 25, 2021 at 1:24 PM Paolo Abeni wrote:
> > When UDP packets generated locally by a socket with UDP_SEGMENT
> > traverse the following path:
> >
> > UDP tunnel(xmit) -> veth (segmentation) -&
On Fri, 2021-03-26 at 14:15 -0400, Willem de Bruijn wrote:
> On Thu, Mar 25, 2021 at 1:24 PM Paolo Abeni wrote:
> > Currently the UDP protocol delivers GSO_FRAGLIST packets to
> > the sockets without the expected segmentation.
> >
> > This change addresses the issue
On Fri, 2021-03-26 at 11:22 +0100, Norman Maurer wrote:
> On 26. Mar 2021, at 10:36, Paolo Abeni wrote:
> > One thing you can do to simplifies the maintainer's life, would be post
> > a v2 with the correct tag (and ev. obsolete this patch in patchwork).
>
> I am quite
ote: I personally think this is more a new feature (is adds
getsockopt support for UDP_GRO) than a fix, so I would not have added
the 'Fixes' tag and I would have targeted net-next, but it's just my
opinion.
Cheers,
Paolo
aggregation
on top of UDP tunnel (vxlan)
v1 -> v2:
- hopefully clarify the commit message
- moved the overlay network ipv6 range into the 'documentation'
reserved range (Willem)
Signed-off-by: Paolo Abeni
---
tools/testing/selftests/net/Makefile | 1 +
tools/testing/
Similar to the previous commit, let even geneve
passthrou the L4 GRO packets
Signed-off-by: Paolo Abeni
---
drivers/net/geneve.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 4ac0373326efd..5d7a2b1469f4c 100644
--- a/drivers/net/geneve.c
Similar to the previous commit, let even geneve
passthrou the L4 GRO packets
Signed-off-by: Paolo Abeni
---
drivers/net/bareudp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/bareudp.c b/drivers/net/bareudp.c
index 7511bca9c15ed..edfad93e7b686 100644
--- a/drivers/net
.
v1 -> v2:
- updated to use the newly introduced UDP socket 'accept*' fields
Signed-off-by: Paolo Abeni
---
drivers/net/vxlan.c | 1 +
include/linux/udp.h | 6 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 7665817f3cb61..39ee130
SO.")
Fixes: 36707061d6ba ("udp: allow forwarding of plain (non-fraglisted) UDP GRO
packets")
Signed-off-by: Paolo Abeni
---
net/ipv4/udp_offload.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_off
pefully clarified most individual patches commit messages
Paolo Abeni (8):
udp: fixup csum for GSO receive slow path
udp: skip L4 aggregation for UDP tunnel packets
udp: properly complete L4 GRO over UDP tunnel packet
udp: never accept GSO_FRAGLIST packets
vxlan: allow L4 GRO passt
tunnel code. Since the issue affects only
this UDP receive slow path, let's set a suitable csum status there.
v1 -> v2:
- restrict the csum update to the packets strictly needing them
- hopefully clarify the commit message and code comments
Signed-off-by: Paolo Abeni
---
in
()
accordingly.
UDP sockets enabling UDP_GRO stil keep accept_udp_fraglist
zeroed.
v1 -> v2:
- use 2 bits instead of a whole GSO bitmask (Willem)
Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
Signed-off-by: Paolo Abeni
---
include/linux/udp.h | 16 +---
n
udp_gro_complete() so that we can enter
the frag list path on the next round, for the inner header.
v1 -> v2:
- hopefully clarified the commit message
Signed-off-by: Paolo Abeni
---
net/ipv4/udp_offload.c | 8 +++-
net/ipv6/udp_offload.c | 3 ++-
2 files changed, 9 insertions(+), 2 deleti
On Thu, 2021-03-25 at 09:53 -0400, Willem de Bruijn wrote:
> On Thu, Mar 25, 2021 at 6:57 AM Paolo Abeni wrote:
> > AFAICS, it depends ;) From skbuff.h:
> >
> > * skb->csum_level indicates the number of consecutive checksums found in
> > * the packet minus
On Wed, 2021-03-24 at 18:12 -0400, Willem de Bruijn wrote:
> On Wed, Mar 24, 2021 at 3:00 PM Paolo Abeni wrote:
> > On Tue, 2021-03-23 at 22:21 -0400, Willem de Bruijn wrote:
> > > On Mon, Mar 22, 2021 at 1:12 PM Paolo Abeni wrote:
> > > > On Mon, 2021-03-22 at
-> veth -> vxlan
> > -> sk
> >
> > scenario. WDYT?
>
> No, let's definitely avoid an unneeded checksum verification.
Ok.
My understanding is that the following should be better:
static inline void udp_post_segment_fix_csum(struct sk_buff *skb)
{
/* UDP-lite can't land here - no GRO */
WARN_ON_ONCE(UDP_SKB_CB(skb)->partial_cov);
/* UDP packets generated with UDP_SEGMENT and traversing:
* UDP tunnel(xmit) -> veth (segmentation) -> veth (gro) -> UDP tunnel
(rx)
* land here with CHECKSUM_NONE. Instead of adding another check
* in the tunnel fastpath, we can force valid csums here:
* packets are locally generated and the GRO engine already validated
* the csum.
* Additionally fixup the UDP CB
*/
UDP_SKB_CB(skb)->cscov = skb->len;
if (skb->ip_summed == CHECKSUM_NONE && !skb->csum_valid)
skb->csum_valid = 1;
}
I'll use the above in v2.
Thanks!
Paolo
On Tue, 2021-03-23 at 22:21 -0400, Willem de Bruijn wrote:
> On Mon, Mar 22, 2021 at 1:12 PM Paolo Abeni wrote:
> > On Mon, 2021-03-22 at 09:42 -0400, Willem de Bruijn wrote:
> > > On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni wrote:
> > > > Currently the UDP protocol
ders will be ignored, too, so that e.g. TCP over vxlan push
packets will be held in the GRO engine till the next flush, etc.
Please let me know if the above is more clear.
Thanks!
Paolo
On Tue, 2021-03-23 at 21:45 -0400, Willem de Bruijn wrote:
> On Mon, Mar 22, 2021 at 12:36 PM Paolo Abeni wrote:
> > On Mon, 2021-03-22 at 09:18 -0400, Willem de Bruijn wrote:
> > > On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni wrote:
> > > > When looping back UDP GSO
r UDP over UDP tunnel traffic
> > +readonly OL_NET_V4=172.16.1.
> > +readonly OL_NET_V6=2002:db8::
>
> is it okay to use a prod64 prefix for this? should this be another
> subnet of 2001:db8:: instead? of fd..
It looks like this comment slipped out of my sight... yep, I'll use
2001:db8:1:: for the overlay network in the next iteration.
Thanks!
Paolo
On Mon, 2021-03-22 at 09:44 -0400, Willem de Bruijn wrote:
> On Sun, Mar 21, 2021 at 1:02 PM Paolo Abeni wrote:
> > create a bunch of virtual topology and verify that
> > GRO_FRAG_LIST and GRO_FWD aggregate the ingress
>
> what are these constants? Aliases for SKB_GSO_FRAGLI
On Mon, 2021-03-22 at 09:42 -0400, Willem de Bruijn wrote:
> On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni wrote:
> > Currently the UDP protocol delivers GSO_FRAGLIST packets to
> > the sockets without the expected segmentation.
> >
> > This change addresses the issue
On Mon, 2021-03-22 at 09:30 -0400, Willem de Bruijn wrote:
> On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni wrote:
> > After the previous patch the stack can do L4 UDP aggregation
> > on top of an UDP tunnel.
> >
> > The current GRO complete code tries frag based aggregat
On Mon, 2021-03-22 at 09:24 -0400, Willem de Bruijn wrote:
> On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni wrote:
> > If UDP GRO forwarding (or list) is enabled,
>
> Please explicitly mention the gso type SKB_GSO_FRAGLIST. I, at least,
> didn't immediately grasp that gro for
On Mon, 2021-03-22 at 09:18 -0400, Willem de Bruijn wrote:
> On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni wrote:
> > When looping back UDP GSO over UDP tunnel packets to an UDP socket,
> > the individual packet csum is currently set to CSUM_NONE. That causes
> > unexpected/
Similar to the previous commit, let even geneve
passthrou the L4 GRO packets
Signed-off-by: Paolo Abeni
---
drivers/net/bareudp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/bareudp.c b/drivers/net/bareudp.c
index 7511bca9c15ed..edfad93e7b686 100644
--- a/drivers/net
create a bunch of virtual topology and verify that
GRO_FRAG_LIST and GRO_FWD aggregate the ingress
packets as expected, and the aggregate packets
are segmented correctly when landing on a socket
Also test L4 aggregation on top of UDP tunnel (vxlan)
Signed-off-by: Paolo Abeni
---
tools/testing
Similar to the previous commit, let even geneve
passthrou the L4 GRO packets
Signed-off-by: Paolo Abeni
---
drivers/net/geneve.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 4ac0373326efd..5d7a2b1469f4c 100644
--- a/drivers/net/geneve.c
-next, as overall it makes available a new feature.
Paolo Abeni (8):
udp: fixup csum for GSO receive slow path
udp: skip fwd/list GRO for tunnel packets
udp: properly complete L4 GRO over UDP tunnel packet
udp: never accept GSO_FRAGLIST packets
vxlan: allow L4 GRO passthrou
geneve: allow
1 - 100 of 1405 matches
Mail list logo
