All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: Vladimir Oltean <olteanv@gmail.com>,
	Linus Walleij <linus.walleij@linaro.org>
Cc: "Hans Ulli Kroll" <ulli.kroll@googlemail.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Michał Mirosław" <mirq-linux@rere.qmqm.pl>,
	"Andrew Lunn" <andrew@lunn.ch>,
	linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v4 0/3] Fix large frames in the Gemini ethernet driver
Date: Thu, 09 Nov 2023 13:26:17 +0100	[thread overview]
Message-ID: <ad66b532d1702c36adecd944e25f84e4497ef8b3.camel@redhat.com> (raw)
In-Reply-To: <20231109105037.zppxrr3bptd7a7i6@skbuf>

On Thu, 2023-11-09 at 12:50 +0200, Vladimir Oltean wrote:
> On Thu, Nov 09, 2023 at 10:03:11AM +0100, Linus Walleij wrote:
> > This is the result of a bug hunt for a problem with the
> > RTL8366RB DSA switch leading me wrong all over the place.
> > 
> > I am indebted to Vladimir Oltean who as usual pointed
> > out where the real problem was, many thanks!
> > 
> > Tryig to actually use big ("jumbo") frames on this
> > hardware uncovered the real bugs. Then I tested it on
> > the DSA switch and it indeed fixes the issue.
> > 
> > To make sure it also works fine with big frames on
> > non-DSA devices I also copied a large video file over
> > scp to a device with maximum frame size, the data
> > was transported in large TCP packets ending up in
> > 0x7ff sized frames using software checksumming at
> > ~2.0 MB/s.
> > 
> > If I set down the MTU to the standard 1500 bytes so
> > that hardware checksumming is used, the scp transfer
> > of the same file was slightly lower, ~1.8-1.9 MB/s.
> > 
> > Despite this not being the best test it shows that
> > we can now stress the hardware with large frames
> > and that software checksum works fine.
> > 
> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> > ---
> 
> Thanks for being persistent with this! I hope we didn't miss today's
> "net" pull request :)

I fear this is a bit too late for today's PR. I hope it should not be a
big problem, since we are very early in the release cycle.

Cheers,

Paolo


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Paolo Abeni <pabeni@redhat.com>
To: Vladimir Oltean <olteanv@gmail.com>,
	Linus Walleij <linus.walleij@linaro.org>
Cc: "Hans Ulli Kroll" <ulli.kroll@googlemail.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Michał Mirosław" <mirq-linux@rere.qmqm.pl>,
	"Andrew Lunn" <andrew@lunn.ch>,
	linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v4 0/3] Fix large frames in the Gemini ethernet driver
Date: Thu, 09 Nov 2023 13:26:17 +0100	[thread overview]
Message-ID: <ad66b532d1702c36adecd944e25f84e4497ef8b3.camel@redhat.com> (raw)
In-Reply-To: <20231109105037.zppxrr3bptd7a7i6@skbuf>

On Thu, 2023-11-09 at 12:50 +0200, Vladimir Oltean wrote:
> On Thu, Nov 09, 2023 at 10:03:11AM +0100, Linus Walleij wrote:
> > This is the result of a bug hunt for a problem with the
> > RTL8366RB DSA switch leading me wrong all over the place.
> > 
> > I am indebted to Vladimir Oltean who as usual pointed
> > out where the real problem was, many thanks!
> > 
> > Tryig to actually use big ("jumbo") frames on this
> > hardware uncovered the real bugs. Then I tested it on
> > the DSA switch and it indeed fixes the issue.
> > 
> > To make sure it also works fine with big frames on
> > non-DSA devices I also copied a large video file over
> > scp to a device with maximum frame size, the data
> > was transported in large TCP packets ending up in
> > 0x7ff sized frames using software checksumming at
> > ~2.0 MB/s.
> > 
> > If I set down the MTU to the standard 1500 bytes so
> > that hardware checksumming is used, the scp transfer
> > of the same file was slightly lower, ~1.8-1.9 MB/s.
> > 
> > Despite this not being the best test it shows that
> > we can now stress the hardware with large frames
> > and that software checksum works fine.
> > 
> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> > ---
> 
> Thanks for being persistent with this! I hope we didn't miss today's
> "net" pull request :)

I fear this is a bit too late for today's PR. I hope it should not be a
big problem, since we are very early in the release cycle.

Cheers,

Paolo


  reply	other threads:[~2023-11-09 12:26 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-09  9:03 [PATCH net v4 0/3] Fix large frames in the Gemini ethernet driver Linus Walleij
2023-11-09  9:03 ` Linus Walleij
2023-11-09  9:03 ` [PATCH net v4 1/3] net: ethernet: cortina: Fix max RX frame define Linus Walleij
2023-11-09  9:03   ` Linus Walleij
2023-11-09 10:42   ` Vladimir Oltean
2023-11-09 10:42     ` Vladimir Oltean
2023-11-09  9:03 ` [PATCH net v4 2/3] net: ethernet: cortina: Handle large frames Linus Walleij
2023-11-09  9:03   ` Linus Walleij
2023-11-09 10:46   ` Vladimir Oltean
2023-11-09 10:46     ` Vladimir Oltean
2023-11-09  9:03 ` [PATCH net v4 3/3] net: ethernet: cortina: Fix MTU max setting Linus Walleij
2023-11-09  9:03   ` Linus Walleij
2023-11-09 10:47   ` Vladimir Oltean
2023-11-09 10:47     ` Vladimir Oltean
2023-11-09 10:50 ` [PATCH net v4 0/3] Fix large frames in the Gemini ethernet driver Vladimir Oltean
2023-11-09 10:50   ` Vladimir Oltean
2023-11-09 12:26   ` Paolo Abeni [this message]
2023-11-09 12:26     ` Paolo Abeni
2023-11-09 17:13     ` Vladimir Oltean
2023-11-09 17:13       ` Vladimir Oltean
2023-11-09 12:46   ` Linus Walleij
2023-11-09 12:46     ` Linus Walleij
2023-11-14  5:00 ` patchwork-bot+netdevbpf
2023-11-14  5:00   ` patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ad66b532d1702c36adecd944e25f84e4497ef8b3.camel@redhat.com \
    --to=pabeni@redhat.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mirq-linux@rere.qmqm.pl \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=ulli.kroll@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.