Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 17 Apr 2023 10:52:29 -0700
From:   Jakub Kicinski <kuba@kernel.org>
To:     Haiyang Zhang <haiyangz@microsoft.com>
Cc:     "linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        Dexuan Cui <decui@microsoft.com>,
        KY Srinivasan <kys@microsoft.com>,
        Paul Rosswurm <paulros@microsoft.com>,
        "olaf@aepfle.de" <olaf@aepfle.de>,
        "vkuznets@redhat.com" <vkuznets@redhat.com>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "wei.liu@kernel.org" <wei.liu@kernel.org>,
        "edumazet@google.com" <edumazet@google.com>,
        "pabeni@redhat.com" <pabeni@redhat.com>,
        "leon@kernel.org" <leon@kernel.org>,
        Long Li <longli@microsoft.com>,
        "ssengar@linux.microsoft.com" <ssengar@linux.microsoft.com>,
        "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
        "daniel@iogearbox.net" <daniel@iogearbox.net>,
        "john.fastabend@gmail.com" <john.fastabend@gmail.com>,
        "bpf@vger.kernel.org" <bpf@vger.kernel.org>,
        "ast@kernel.org" <ast@kernel.org>,
        Ajay Sharma <sharmaajay@microsoft.com>,
        "hawk@kernel.org" <hawk@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V3,net-next, 3/4] net: mana: Enable RX path to handle
 various MTU sizes
Message-ID: <20230417105229.7d1eb988@kernel.org>
In-Reply-To: <PH7PR21MB3116023068CFA8D600FA5B18CA9E9@PH7PR21MB3116.namprd21.prod.outlook.com>
References: <1681334163-31084-1-git-send-email-haiyangz@microsoft.com>
        <1681334163-31084-4-git-send-email-haiyangz@microsoft.com>
        <20230414190608.3c21f44f@kernel.org>
        <PH7PR21MB3116023068CFA8D600FA5B18CA9E9@PH7PR21MB3116.namprd21.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Sat, 15 Apr 2023 14:25:29 +0000 Haiyang Zhang wrote:
> > Allocating frag larger than a page is not safe. =20
>=20
>  I saw other drivers doing this - use napi_alloc_frag for size bigger tha=
n a page.
> And it returns compound page. Why it's not safe? Should we use other allo=
cator
> when need compound pages?

I believe so. There was a thread about this within the last year.
Someone was trying to fix the page frag allocator to not fall back
to order 0 pages in case of failure if requested size is > PAGE_SIZE.
But there was push back and folks were saying that it's simply not=20
a case supported by the frag allocator. =F0=9F=A4=B7=EF=B8=8F

> > Frag allocator falls back to allocating single pages, doesn't it? =20
>=20
> Actually I checked it. Compound page is still returned for size smaller t=
han PAGE_SIZE,
> so I used single page allocation for that.

https://elixir.bootlin.com/linux/v6.3-rc6/source/mm/page_alloc.c#L5723

Jumbo frames should really be supported as scatter transfers,=20
if possible.