[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM0PR04MB4723AA2ABCE91928BE735DEBD46E9@AM0PR04MB4723.eurprd04.prod.outlook.com>
Date: Mon, 1 May 2023 11:59:42 +0000
From: Alvaro Karsz <alvaro.karsz@...id-run.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
CC: "jasowang@...hat.com" <jasowang@...hat.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"edumazet@...gle.com" <edumazet@...gle.com>,
"kuba@...nel.org" <kuba@...nel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"virtualization@...ts.linux-foundation.org"
<virtualization@...ts.linux-foundation.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"xuanzhuo@...ux.alibaba.com" <xuanzhuo@...ux.alibaba.com>
Subject: Re: [RFC PATCH net 2/3] virtio-net: allow usage of vrings smaller
than MAX_SKB_FRAGS + 2
> First up to 4k should not be a problem. Even jumbo frames e.g. 9k
> is highly likely to succeed. And a probe time which is often boot
> even 64k isn't a problem ...
>
> Hmm. We could allocate large buffers at probe time. Reuse them and
> copy data over.
>
> IOW reusing GOOD_COPY_LEN flow for this case. Not yet sure how I feel
> about this. OTOH it removes the need for the whole feature blocking
> approach, does it not?
> WDYT?
>
It could work..
In order to remove completely the feature blocking approach, we'll need to let the control commands fail (as you mentioned in the other patch).
I'm not sure I like it, it means many warnings from virtnet..
And it means accepting features that we know for sure that are not going to work.
Powered by blists - more mailing lists