Received-SPF: pass (google.com: domain of linux-kernel+bounces-160523-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <20240423134731.918157-1-vinschen@redhat.com> <CANn89iKv1J3AS3rEmEhFq5McHmM+L=32pWg3Wj4_drsdKUx77A@mail.gmail.com>
 <Ziu6k5cjXsaUpAYH@calimero.vinschen.de>
In-Reply-To: <Ziu6k5cjXsaUpAYH@calimero.vinschen.de>
From: Eric Dumazet <edumazet@google.com>
Date: Fri, 26 Apr 2024 19:54:52 +0200
Message-ID: <CANn89iJ_eM2oK5ruGu1NMk0ZEivEQO=R64E9eb9ujYj+=qWiKA@mail.gmail.com>
Subject: Re: [PATCH net v2] igb: cope with large MAX_SKB_FRAGS
To: Eric Dumazet <edumazet@google.com>, netdev@vger.kernel.org, 
	linux-kernel@vger.kernel.org, intel-wired-lan@lists.osuosl.org, 
	Nikolay Aleksandrov <razor@blackwall.org>, Jason Xing <kerneljasonxing@gmail.com>, 
	Paolo Abeni <pabeni@redhat.com>, Jakub Kicinski <kuba@kernel.org>, 
	"David S . Miller" <davem@davemloft.net>, Tony Nguyen <anthony.l.nguyen@intel.com>, 
	Jesse Brandeburg <jesse.brandeburg@intel.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 26, 2024 at 4:30=E2=80=AFPM Corinna Vinschen <vinschen@redhat.c=
om> wrote:
>
> Hi Eric,
>
> On Apr 23 16:10, Eric Dumazet wrote:
> > On Tue, Apr 23, 2024 at 3:47=E2=80=AFPM Corinna Vinschen <vinschen@redh=
at.com> wrote:
> > >
> > > From: Paolo Abeni <pabeni@redhat.com>
> > >
> > > Sabrina reports that the igb driver does not cope well with large
> > > MAX_SKB_FRAG values: setting MAX_SKB_FRAG to 45 causes payload
> > > corruption on TX.
> > >
> > > An easy reproducer is to run ssh to connect to the machine.  With
> > > MAX_SKB_FRAGS=3D17 it works, with MAX_SKB_FRAGS=3D45 it fails.
> > >
> > > The root cause of the issue is that the driver does not take into
> > > account properly the (possibly large) shared info size when selecting
> > > the ring layout, and will try to fit two packets inside the same 4K
> > > page even when the 1st fraglist will trump over the 2nd head.
> > >
> > > Address the issue forcing the driver to fit a single packet per page,
> > > leaving there enough room to store the (currently) largest possible
> > > skb_shared_info.
> > >
> > > Fixes: 3948b05950fd ("net: introduce a config option to tweak MAX_SKB=
_FRAG")
> > > Reported-by: Jan Tluka <jtluka@redhat.com>
> > > Reported-by: Jirka Hladky <jhladky@redhat.com>
> > > Reported-by: Sabrina Dubroca <sd@queasysnail.net>
> > > Tested-by: Sabrina Dubroca <sd@queasysnail.net>
> > > Tested-by: Corinna Vinschen <vinschen@redhat.com>
> > > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> > > ---
> > > v2: fix subject, add a simple reproducer
> > >
> > >  drivers/net/ethernet/intel/igb/igb_main.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/=
ethernet/intel/igb/igb_main.c
> > > index a3f100769e39..22fb2c322bca 100644
> > > --- a/drivers/net/ethernet/intel/igb/igb_main.c
> > > +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> > > @@ -4833,6 +4833,7 @@ static void igb_set_rx_buffer_len(struct igb_ad=
apter *adapter,
> > >
> > >  #if (PAGE_SIZE < 8192)
> > >         if (adapter->max_frame_size > IGB_MAX_FRAME_BUILD_SKB ||
> > > +           SKB_HEAD_ALIGN(adapter->max_frame_size) > (PAGE_SIZE / 2)=
 ||
> >
> > I wonder if adding IGB_SKB_PAD would be needed ?
> >
> > adapter->max_frame_size does not seem to include it.
> >
> > I would try using all mtus between 1200 and 1280 to make sure this work=
s.
>
> Erm... did you mean between 1500 and 1580 by any chance?  1200 doesn't
> really seem to make sense...

No, I meant 1200 to 1280 .  IPv4 should accept these MTU .

1200 + 768 =3D 1968
1280 + 768 =3D 2048 (2 KB)

I am worried of some padding that would cross 2048 bytes boundary,
while SKB_HEAD_ALIGN(adapter->max_frame_size) could still be < 2048


>
> I tested this patch now with mtu 1500, 1540 and 1580 successfully.
>
> Either way, I'm just heading into vacation, so I guess I'll pick this up
> again when I'm back, unless Paolo takes another look during my absence.
>

I guess your patch is better than nothing, this can be refined if
necessary later.