t; Reviewed-by: David Gibson
> Reviewed-by: Stefano Brivio
> Tested-by: Stefano Brivio
> Signed-off-by: Jon Maloy
Reviewed-by: Eric Dumazet
Thanks.
ol != IPPROTO_TCP)
> + return -EBADF;
This might use sk_is_tcp() helper.
> +
> + if (optlen % sizeof(struct dmabuf_token) ||
> + optlen > sizeof(*tokens) * 128)
> + return -EINVAL;
> +
> + tokens = kvmalloc_array(128, sizeof(*tokens), GFP_KERNEL);
This allocates 8192 bytes even for small optlen ?
Probably no big deal, no need to send a new version.
Reviewed-by: Eric Dumazet
g this page. All pages are released when the socket is
> destroyed.
>
> Signed-off-by: Willem de Bruijn
> Signed-off-by: Kaiyuan Zhang
> Signed-off-by: Mina Almasry
Reviewed-by: Eric Dumazet
b1->unreadable = skb->unreadable;
> skb_shinfo(skb)->nr_frags = 0;
> skb1->data_len = skb->data_len;
> skb1->len += skb1->data_len;
> @@ -4071,6 +4099,7 @@ static inline void skb_split_no_header(struct sk_buff
> *skb,
> {
> int i, k = 0;
> const int nfrags = skb_shinfo(skb)->nr_frags;
> + const int unreadable = skb->unreadable;
>
> skb_shinfo(skb)->nr_frags = 0;
> skb1->len = skb1->data_len = skb->len - len;
> @@ -4104,6 +4133,12 @@ static inline void skb_split_no_header(struct sk_buff
> *skb,
> pos += size;
> }
> skb_shinfo(skb1)->nr_frags = k;
> +
Minor point : skb->unreadable can be left as is ?
> + if (skb_shinfo(skb)->nr_frags)
> + skb->unreadable = unreadable;
Minor point : skb_shinfo(skb1)->nr_frags can't be zero at this point.
> +
> + if (skb_shinfo(skb1)->nr_frags)
> + skb1->unreadable = unreadable;
> }
This means we probably could remove the unreadable variable and
skb1->unreadable = skb->unreadable;
No need to send a new version, this can be incrementally changed later.
Reviewed-by: Eric Dumazet
On Fri, Jun 28, 2024 at 2:33 AM Mina Almasry wrote:
>
> Make skb_frag_page() fail in the case where the frag is not backed
> by a page, and fix its relevant callers to handle this case.
>
> Signed-off-by: Mina Almasry
>
Reviewed-by: Eric Dumazet
On Tue, Jun 25, 2024 at 10:25 AM Geliang Tang wrote:
>
> From: Geliang Tang
>
> Run the following BPF selftests on Loongarch:
>
> ./test_progs -t sockmap_basic
>
> A Kernel panic occurs:
>
> '''
> Oops[#1]:
> CPU: 22 PID: 2824 Comm: test_progs Tainted: G OE 6.10.0-rc2+
> #18
>
On Tue, Jun 25, 2024 at 10:25 AM Geliang Tang wrote:
>
> From: Geliang Tang
>
> Run the following BPF selftests on Loongarch:
>
> ./test_progs -t sockmap_listen
>
> A Kernel panic occurs:
>
> '''
> Oops[#1]:
> CPU: 49 PID: 233429 Comm: new_name Tainted: G OE 6.10.0-rc2+
> #20
>
On Mon, Jun 24, 2024 at 3:28 PM Geliang Tang wrote:
>
> From: Geliang Tang
>
> Run the following BPF selftests on loongarch:
>
> # ./test_progs -t sockmap_basic
>
> A Kernel panic occurs:
>
> '''
> Oops[#1]:
> CPU: 22 PID: 2824 Comm: test_progs Tainted: G OE 6.10.0-rc2+
> #18
>
On Mon, Jun 24, 2024 at 3:28 PM Geliang Tang wrote:
>
> From: Geliang Tang
>
> Run the following BPF selftests on loongarch:
>
> # ./test_progs -t sockmap_listen
>
> A Kernel panic occurs:
>
> '''
> Oops[#1]:
> CPU: 49 PID: 233429 Comm: new_name Tainted: G OE 6.10.0-rc2+
> #20
>
eters available readonly from within a
> network namespace, allowing a container to read them.
>
> Signed-off-by: Matteo Croce
Reviewed-by: Eric Dumazet
ftest to make sure the issue doesn't get reintroduced.
>
> Fixes: 09dbdf28f9f9 ("net/sched: taprio: fix calculation of maximum gate
> durations")
> Signed-off-by: Vladimir Oltean
Reviewed-by: Eric Dumazet
Thanks!
On Thu, May 9, 2024 at 8:58 PM Richard Gobert wrote:
>
>
> Interesting, I think that is indeed a bug, that exists also in the current
> implementation.
> NAPI_GRO_CB(p)->ip_fixedid (is_atomic before we renamed it in this commit)
> is cleared as being part of NAPI_GRO_CB(skb)->zeroed in dev_gro_re
On Tue, May 7, 2024 at 6:30 PM Richard Gobert wrote:
>
> {inet,ipv6}_gro_receive functions perform flush checks (ttl, flags,
> iph->id, ...) against all packets in a loop. These flush checks are used in
> all merging UDP and TCP flows.
>
> These checks need to be done only once and only against th
On Mon, Apr 22, 2024 at 3:48 PM Jakub Kicinski wrote:
>
> On Sun, 21 Apr 2024 13:32:24 -0600 David Ahern wrote:
> > On 4/21/24 1:17 PM, Eric Dumazet wrote:
> > > I wonder if NLM_F_DUMP_FILTERED should not be reported to user space ?
> >
> > good point. We do set
On Sat, Apr 20, 2024 at 4:35 AM Jakub Kicinski wrote:
>
> Having to filter the right ifindex in the tests is a bit tedious.
> Add support for dumping qstats for a single ifindex.
>
> Signed-off-by: Jakub Kicinski
> ---
> Documentation/netlink/specs/netdev.yaml | 1 +
> net/core/netdev-genl-gen.
On Fri, Apr 5, 2024 at 3:06 PM Matthieu Baerts (NGI0)
wrote:
>
> From: Geliang Tang
>
> This patch adds "last time" fields last_data_sent, last_data_recv and
> last_ack_recv in struct mptcp_sock to record the last time data_sent,
> data_recv and ack_recv happened. They all are initialized as
> tc
On Tue, Mar 26, 2024 at 3:43 PM Richard Gobert wrote:
>
> Eric Dumazet wrote:
> > On Mon, Mar 25, 2024 at 7:27 PM Richard Gobert
> > wrote:
> >>
> >> {inet,ipv6}_gro_receive functions perform flush checks (ttl, flags,
> >> iph->id, ...) against al
On Mon, Mar 25, 2024 at 7:27 PM Richard Gobert wrote:
>
> {inet,ipv6}_gro_receive functions perform flush checks (ttl, flags,
> iph->id, ...) against all packets in a loop. These flush checks are used
> currently only in tcp flows in GRO.
I think this is a bug.
GRO should not aggregate packets i
On Sat, Mar 9, 2024 at 4:35 PM Richard Gobert wrote:
>
> {inet,ipv6}_gro_receive functions perform flush checks (ttl, flags,
> iph->id, ...) against all packets in a loop. These flush checks are
> relevant only to tcp flows, and as such they're used to determine whether
> the packets can be merged
On Thu, Mar 7, 2024 at 2:28 PM Richard Gobert wrote:
>
> This patch sets network_header and inner_network_header to their respective
> values during the receive phase of GRO. This allows us to use
> inner_network_header later on in GRO. network_header is already set in
> dev_gro_receive and under
On Thu, Feb 29, 2024 at 2:22 PM Richard Gobert wrote:
>
>
>
> Eric Dumazet wrote:
> >
> > My intuition is that this patch has a high cost for normal GRO processing.
> > SW-GRO is already a bottleneck on ARM cores in smart NICS.
> >
> > I would suggest
On Sat, Feb 24, 2024 at 10:04 AM Dmitry Safonov wrote:
>
> Two reasons:
> 1. It's grown up enough
> 2. In order to not do header spaghetti by including
>, which is necessary for TCP tracepoints.
>
> Signed-off-by: Dmitry Safonov
Okay, but what about CONFIG_IPV6=m ?
I do not see any EXPORT_S
On Thu, Feb 22, 2024 at 10:05 PM Richard Gobert
wrote:
>
> Commits a602456 ("udp: Add GRO functions to UDP socket") and 57c67ff ("udp:
> additional GRO support") introduce incorrect usage of {ip,ipv6}_hdr in the
> complete phase of gro. The functions always return skb->network_header,
> which in t
On Tue, Feb 20, 2024 at 6:33 PM Paolo Abeni wrote:
>
> On Mon, 2024-02-19 at 19:33 +0100, Eric Dumazet wrote:
> > On Mon, Feb 19, 2024 at 7:04 PM Paolo Abeni wrote:
> > > Thanks for the head-up. This later option looks preferable, to avoid
> > > quit a bit of n
On Mon, Feb 19, 2024 at 7:04 PM Paolo Abeni wrote:
>
> On Mon, 2024-02-19 at 18:35 +0100, Eric Dumazet wrote:
> > On Mon, Feb 19, 2024 at 6:21 PM Eric Dumazet wrote:
> > >
> > > On Thu, Feb 15, 2024 at 7:25 PM Matthieu Baerts (NGI0)
> > > w
On Mon, Feb 19, 2024 at 6:21 PM Eric Dumazet wrote:
>
> On Thu, Feb 15, 2024 at 7:25 PM Matthieu Baerts (NGI0)
> wrote:
> >
> > From: Paolo Abeni
> >
> > Since the introduction of the subflow ULP diag interface, the
> > dump callback accessed all the subf
On Thu, Feb 15, 2024 at 7:25 PM Matthieu Baerts (NGI0)
wrote:
>
> From: Paolo Abeni
>
> Since the introduction of the subflow ULP diag interface, the
> dump callback accessed all the subflow data with lockless.
>
> We need either to annotate all the read and write operation accordingly,
> or acqu
On Wed, Feb 7, 2024 at 6:31 PM Paolo Abeni wrote:
>
> The reuseport_addr_any.sh is currently skipping DCCP tests and
> pmtu.sh is skipping all the FOU/GUE related cases: add the missing
> options.
>
> Signed-off-by: Paolo Abeni
> ---
SGTM thanks.
Reviewed-by: Eric Dumazet
- -m
> 262144 2>&1 >/dev/null
> }
Interesting.
I think we set tcp_wmem[1] to 262144 in our hosts. I think netperf
default depends on tcp_wmem[1]
Reviewed-by: Eric Dumazet
On Fri, Feb 2, 2024 at 1:12 AM Jakub Kicinski wrote:
>
> Paolo points out that ifconfig is legacy and we should not use it.
>
> Signed-off-by: Jakub Kicinski
Reviewed-by: Eric Dumazet
"selftests/net: allow GRO coalesce test on veth")
> Signed-off-by: Paolo Abeni
Reviewed-by: Eric Dumazet
Tested-by: Eric Dumazet
On Thu, Jan 25, 2024 at 5:40 PM Paolo Abeni wrote:
>
>
> Thank you for testing!
>
> Do you prefer I'll send the formal patch or do you prefer otherwise?
Please send it, you did the investigations, thanks a lot !
On Thu, Jan 25, 2024 at 12:38 PM Paolo Abeni wrote:
>
> On Thu, 2024-01-25 at 09:48 +0100, Eric Dumazet wrote:
> > On Thu, Jan 25, 2024 at 9:23 AM Paolo Abeni wrote:
> > >
> > > the udpgro_fraglist self-test uses the BPF classifiers, but the
> > > curre
uot;selftests net: add UDP GRO fraglist + bpf self-tests")
> Signed-off-by: Paolo Abeni
FYI, while looking at the gro test, I found that using strace was
making it failing as well.
Not sure about this one...
Reviewed-by: Eric Dumazet
s no modification of skb->data, all
> operations use skb_gro_* helpers, and the frag0 fast path can be taken for
> IPv6 packets with ext headers.
>
> Signed-off-by: Richard Gobert
> Reviewed-by: Willem de Bruijn
> Reviewed-by: David Ahern
Reviewed-by: Eric Dumazet
Thanks !
On Wed, Jan 3, 2024 at 2:08 PM Richard Gobert wrote:
>
>
>
> Eric Dumazet wrote:
> > On Tue, Jan 2, 2024 at 2:25 PM Richard Gobert
> > wrote:
> >>
> >> The existing code always pulls the IPv6 header and sets the transport
> >> offset initially
On Tue, Jan 2, 2024 at 2:25 PM Richard Gobert wrote:
>
> The existing code always pulls the IPv6 header and sets the transport
> offset initially. Then optionally again pulls any extension headers in
> ipv6_gso_pull_exthdrs and sets the transport offset again on return from
> that call. skb->data
and parsing an incoming packet.
>
> Signed-off-by: Richard Gobert
> Reviewed-by: Willem de Bruijn
Reviewed-by: Eric Dumazet
hat 0 are queued, 20 dropped
> 4. send 20 pkts on band B: verify that 10 are queued, 10 dropped
>
>
...
> Signed-off-by: Willem de Bruijn
> ---
Thanks Willem for upstreaming this test.
Reviewed-by: Eric Dumazet
On Tue, Nov 7, 2023 at 10:05 PM Stanislav Fomichev wrote:
>
> I don't understand. We require an elaborate setup to receive devmem cmsgs,
> why would some random application receive those?
A TCP socket can receive 'valid TCP packets' from many different sources,
especially with BPF hooks...
Thi
40 matches
Mail list logo
