From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: Si-Wei Liu <si-wei.liu@oracle.com>,
Jason Wang <jasowang@redhat.com>, Gavin Li <gavinl@nvidia.com>,
"Hemminger, Stephen" <stephen@networkplumber.org>,
davem <davem@davemloft.net>,
virtualization <virtualization@lists.linux-foundation.org>,
Virtio-Dev <virtio-dev@lists.oasis-open.org>,
"jesse.brandeburg@intel.com" <jesse.brandeburg@intel.com>,
"alexander.h.duyck@intel.com" <alexander.h.duyck@intel.com>,
"kubakici@wp.pl" <kubakici@wp.pl>,
"sridhar.samudrala@intel.com" <sridhar.samudrala@intel.com>,
"loseweigh@gmail.com" <loseweigh@gmail.com>,
Gavi Teitz <gavi@nvidia.com>
Subject: Re: [virtio-dev] [PATCH] virtio-net: use mtu size as buffer length for big packets
Date: Tue, 9 Aug 2022 17:32:02 -0400 [thread overview]
Message-ID: <20220809173024-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <PH0PR12MB5481B4552000CF20B0F73B4BDC629@PH0PR12MB5481.namprd12.prod.outlook.com>
On Tue, Aug 09, 2022 at 09:13:42PM +0000, Parav Pandit wrote:
> > From: Si-Wei Liu <si-wei.liu@oracle.com>
> > Sent: Tuesday, August 9, 2022 4:33 PM
> >
> > On 8/9/2022 12:18 PM, Parav Pandit wrote:
> > >> From: Si-Wei Liu <si-wei.liu@oracle.com>
> > >> Sent: Tuesday, August 9, 2022 3:09 PM
> > >>>> From: Si-Wei Liu <si-wei.liu@oracle.com>
> > >>>> Sent: Tuesday, August 9, 2022 2:39 PM Currently it is not. Not a
> > >>>> single patch nor this patch, but the context for the eventual goal
> > >>>> is to allow XDP on a MTU=9000 link when guest users intentionally
> > >>>> lower down MTU to 1500.
> > >>> Which application benefit by having asymmetry by lowering mtu to
> > >>> 1500
> > >> to send packets but want to receive 9K packets?
> > > Below details doesn’t answer the question of asymmetry. :)
> > >
> > >> I think virtio-net driver doesn't differentiate MTU and MRU, in which
> > >> case the receive buffer will be reduced to fit the 1500B payload size
> > >> when mtu is lowered down to 1500 from 9000.
> > > How? Driver reduced the mXu to 1500, say it is improved to post buffers of
> > 1500 bytes.
> > For big_packet path, yes, we need improvement; for mergeable, it's
> > adaptable to any incoming packet size so 1500 is what it is today.
> > >
> > > Device doesn't know about it because mtu in config space is RO field.
> > > Device keep dropping 9K packets because buffers posted are 1500 bytes.
> > > This is because device follows the spec " The device MUST NOT pass
> > received packets that exceed mtu".
> > Right, that's what it happens today on device side (i.e. vhost-net, btw
> > mlx5 vdpa device seems to have a bug not pro-actively dropping packets that
> > exceed the MTU size, causing guest panic in small packet path).
> > >
> > > So, I am lost what virtio net device user application is trying to achieve by
> > sending smaller packets and dropping all receive packets.
> > > (it doesn’t have any relation to mergeable or otherwise).
> >
> > Usually, the use case I'm aware of would set the peer's MTU to 1500 (e.g. on
> > a virtual network appliance), or it would rely on path mtu discovery to avoid
> > packet drop across links.
> Ok. Somehow the application knows the mtu to set on (all) peer(s) and hope for the best.
> Understood.
That's generally what one has to do with mtu, yes - it has to be set
consistently across the LAN. While e.g. pMTU might help work around some
misconfigured LANs with a mix of different MTUs it was never designed
for that.
--
MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: "alexander.h.duyck@intel.com" <alexander.h.duyck@intel.com>,
Virtio-Dev <virtio-dev@lists.oasis-open.org>,
"kubakici@wp.pl" <kubakici@wp.pl>,
"sridhar.samudrala@intel.com" <sridhar.samudrala@intel.com>,
"jesse.brandeburg@intel.com" <jesse.brandeburg@intel.com>,
Gavi Teitz <gavi@nvidia.com>,
virtualization <virtualization@lists.linux-foundation.org>,
"Hemminger, Stephen" <stephen@networkplumber.org>,
"loseweigh@gmail.com" <loseweigh@gmail.com>,
davem <davem@davemloft.net>, Gavin Li <gavinl@nvidia.com>
Subject: Re: [virtio-dev] [PATCH] virtio-net: use mtu size as buffer length for big packets
Date: Tue, 9 Aug 2022 17:32:02 -0400 [thread overview]
Message-ID: <20220809173024-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <PH0PR12MB5481B4552000CF20B0F73B4BDC629@PH0PR12MB5481.namprd12.prod.outlook.com>
On Tue, Aug 09, 2022 at 09:13:42PM +0000, Parav Pandit wrote:
> > From: Si-Wei Liu <si-wei.liu@oracle.com>
> > Sent: Tuesday, August 9, 2022 4:33 PM
> >
> > On 8/9/2022 12:18 PM, Parav Pandit wrote:
> > >> From: Si-Wei Liu <si-wei.liu@oracle.com>
> > >> Sent: Tuesday, August 9, 2022 3:09 PM
> > >>>> From: Si-Wei Liu <si-wei.liu@oracle.com>
> > >>>> Sent: Tuesday, August 9, 2022 2:39 PM Currently it is not. Not a
> > >>>> single patch nor this patch, but the context for the eventual goal
> > >>>> is to allow XDP on a MTU=9000 link when guest users intentionally
> > >>>> lower down MTU to 1500.
> > >>> Which application benefit by having asymmetry by lowering mtu to
> > >>> 1500
> > >> to send packets but want to receive 9K packets?
> > > Below details doesn’t answer the question of asymmetry. :)
> > >
> > >> I think virtio-net driver doesn't differentiate MTU and MRU, in which
> > >> case the receive buffer will be reduced to fit the 1500B payload size
> > >> when mtu is lowered down to 1500 from 9000.
> > > How? Driver reduced the mXu to 1500, say it is improved to post buffers of
> > 1500 bytes.
> > For big_packet path, yes, we need improvement; for mergeable, it's
> > adaptable to any incoming packet size so 1500 is what it is today.
> > >
> > > Device doesn't know about it because mtu in config space is RO field.
> > > Device keep dropping 9K packets because buffers posted are 1500 bytes.
> > > This is because device follows the spec " The device MUST NOT pass
> > received packets that exceed mtu".
> > Right, that's what it happens today on device side (i.e. vhost-net, btw
> > mlx5 vdpa device seems to have a bug not pro-actively dropping packets that
> > exceed the MTU size, causing guest panic in small packet path).
> > >
> > > So, I am lost what virtio net device user application is trying to achieve by
> > sending smaller packets and dropping all receive packets.
> > > (it doesn’t have any relation to mergeable or otherwise).
> >
> > Usually, the use case I'm aware of would set the peer's MTU to 1500 (e.g. on
> > a virtual network appliance), or it would rely on path mtu discovery to avoid
> > packet drop across links.
> Ok. Somehow the application knows the mtu to set on (all) peer(s) and hope for the best.
> Understood.
That's generally what one has to do with mtu, yes - it has to be set
consistently across the LAN. While e.g. pMTU might help work around some
misconfigured LANs with a mix of different MTUs it was never designed
for that.
--
MST
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2022-08-09 21:32 UTC|newest]
Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-02 4:45 [virtio-dev] [PATCH] virtio-net: use mtu size as buffer length for big packets Gavin Li
2022-08-04 5:00 ` Jason Wang
2022-08-04 5:00 ` Jason Wang
2022-08-04 7:10 ` Michael S. Tsirkin
2022-08-04 7:10 ` Michael S. Tsirkin
2022-08-04 7:23 ` Jason Wang
2022-08-04 7:23 ` Jason Wang
2022-08-04 7:24 ` Jason Wang
2022-08-04 7:24 ` Jason Wang
2022-08-08 6:54 ` Gavin Li
2022-08-08 6:24 ` Gavin Li
2022-08-05 22:11 ` Si-Wei Liu
2022-08-05 22:11 ` Si-Wei Liu
2022-08-05 23:26 ` Si-Wei Liu
2022-08-05 23:26 ` Si-Wei Liu
2022-08-08 7:34 ` Gavin Li
2022-08-08 7:31 ` Gavin Li
2022-08-08 23:56 ` Si-Wei Liu
2022-08-08 23:56 ` Si-Wei Liu
2022-08-09 7:06 ` Gavin Li
2022-08-09 7:44 ` Jason Wang
2022-08-09 7:44 ` Jason Wang
2022-08-09 9:22 ` Michael S. Tsirkin
2022-08-09 9:22 ` Michael S. Tsirkin
2022-08-09 9:28 ` Jason Wang
2022-08-09 9:28 ` Jason Wang
2022-08-09 9:25 ` Michael S. Tsirkin
2022-08-09 9:25 ` Michael S. Tsirkin
2022-08-09 9:40 ` Jason Wang
2022-08-09 9:40 ` Jason Wang
2022-08-09 18:38 ` Si-Wei Liu
2022-08-09 18:38 ` Si-Wei Liu
2022-08-09 18:42 ` Parav Pandit
2022-08-09 18:42 ` Parav Pandit via Virtualization
2022-08-09 19:08 ` Si-Wei Liu
2022-08-09 19:08 ` Si-Wei Liu
2022-08-09 19:18 ` Parav Pandit
2022-08-09 19:18 ` Parav Pandit via Virtualization
2022-08-09 20:32 ` Si-Wei Liu
2022-08-09 20:32 ` Si-Wei Liu
2022-08-09 21:13 ` Parav Pandit
2022-08-09 21:13 ` Parav Pandit via Virtualization
2022-08-09 21:32 ` Michael S. Tsirkin [this message]
2022-08-09 21:32 ` Michael S. Tsirkin
2022-08-09 21:37 ` Michael S. Tsirkin
2022-08-09 21:37 ` Michael S. Tsirkin
2022-08-09 21:49 ` Parav Pandit
2022-08-09 21:49 ` Parav Pandit via Virtualization
2022-08-09 22:25 ` Michael S. Tsirkin
2022-08-09 22:25 ` Michael S. Tsirkin
2022-08-09 22:49 ` Parav Pandit
2022-08-09 22:49 ` Parav Pandit via Virtualization
2022-08-09 22:59 ` Michael S. Tsirkin
2022-08-09 22:59 ` Michael S. Tsirkin
2022-08-09 23:04 ` Michael S. Tsirkin
2022-08-09 23:04 ` Michael S. Tsirkin
2022-08-09 23:24 ` Si-Wei Liu
2022-08-09 23:24 ` Si-Wei Liu
2022-08-10 6:14 ` Michael S. Tsirkin
2022-08-10 6:14 ` Michael S. Tsirkin
2022-08-10 6:15 ` Michael S. Tsirkin
2022-08-10 6:15 ` Michael S. Tsirkin
2022-08-10 6:59 ` Jason Wang
2022-08-10 6:59 ` Jason Wang
2022-08-10 9:03 ` Michael S. Tsirkin
2022-08-10 9:03 ` Michael S. Tsirkin
2022-08-10 16:00 ` Parav Pandit
2022-08-10 16:00 ` Parav Pandit via Virtualization
2022-08-10 16:05 ` Michael S. Tsirkin
2022-08-10 16:05 ` Michael S. Tsirkin
2022-08-10 16:22 ` Parav Pandit
2022-08-10 16:22 ` Parav Pandit via Virtualization
2022-08-10 16:58 ` Michael S. Tsirkin
2022-08-10 16:58 ` Michael S. Tsirkin
2022-08-10 17:02 ` Michael S. Tsirkin
2022-08-10 17:02 ` Michael S. Tsirkin
2022-08-10 17:06 ` Parav Pandit
2022-08-10 17:06 ` Parav Pandit via Virtualization
2022-08-10 17:12 ` Michael S. Tsirkin
2022-08-10 17:12 ` Michael S. Tsirkin
2022-08-11 0:26 ` Si-Wei Liu
2022-08-11 0:26 ` Si-Wei Liu
2022-08-09 22:32 ` Si-Wei Liu
2022-08-09 22:32 ` Si-Wei Liu
2022-08-09 22:37 ` Michael S. Tsirkin
2022-08-09 22:37 ` Michael S. Tsirkin
2022-08-09 22:54 ` Si-Wei Liu
2022-08-09 22:54 ` Si-Wei Liu
2022-08-09 23:03 ` Michael S. Tsirkin
2022-08-09 23:03 ` Michael S. Tsirkin
2022-08-10 1:24 ` Jason Wang
2022-08-10 1:24 ` Jason Wang
2022-08-09 21:34 ` Michael S. Tsirkin
2022-08-09 21:34 ` Michael S. Tsirkin
2022-08-09 21:39 ` Si-Wei Liu
2022-08-09 21:39 ` Si-Wei Liu
2022-08-09 22:27 ` Michael S. Tsirkin
2022-08-09 22:27 ` Michael S. Tsirkin
2022-08-10 1:15 ` Jason Wang
2022-08-10 1:15 ` Jason Wang
2022-08-09 18:06 ` Si-Wei Liu
2022-08-09 18:06 ` Si-Wei Liu
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=20220809173024-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=alexander.h.duyck@intel.com \
--cc=davem@davemloft.net \
--cc=gavi@nvidia.com \
--cc=gavinl@nvidia.com \
--cc=jasowang@redhat.com \
--cc=jesse.brandeburg@intel.com \
--cc=kubakici@wp.pl \
--cc=loseweigh@gmail.com \
--cc=parav@nvidia.com \
--cc=si-wei.liu@oracle.com \
--cc=sridhar.samudrala@intel.com \
--cc=stephen@networkplumber.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=virtualization@lists.linux-foundation.org \
/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.