Linux virtualization list
 help / color / mirror / Atom feed
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: Wed, 10 Aug 2022 13:02:21 -0400	[thread overview]
Message-ID: <20220810125935-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20220810125749-mutt-send-email-mst@kernel.org>

On Wed, Aug 10, 2022 at 12:58:58PM -0400, Michael S. Tsirkin wrote:
> On Wed, Aug 10, 2022 at 04:22:41PM +0000, Parav Pandit wrote:
> > 
> > > From: Michael S. Tsirkin <mst@redhat.com>
> > > Sent: Wednesday, August 10, 2022 12:05 PM
> > > 
> > > On Wed, Aug 10, 2022 at 04:00:08PM +0000, Parav Pandit wrote:
> > > >
> > > > > From: Michael S. Tsirkin <mst@redhat.com>
> > > > > Sent: Wednesday, August 10, 2022 5:03 AM
> > > > > > >
> > > > > > > Should we make this depend on the vq reset ability maybe?
> > > > > >
> > > > > > The advantage of this is to keep TX working. Or we can use device
> > > > > > reset as a fallback if there's no vq reset.
> > > > > >
> > > > > > Thanks
> > > > >
> > > > > Device reset is really annoying in that it loses all the state:
> > > > > rx filters etc etc.
> > > >
> > > > The elegant solution is let driver tell the new mtu to the device.
> > > > One way to do so is by using existing ctrl vq.
> > > 
> > > That will need a new feature bit.
> > > 
> > Yes. ctrl vq can tell what all configuration does it allow. :)
> > Or you prefer feature bit?
> 
> We did feature bits for this in the past.
> 
> > > > If merged buffer is done, and new mtu is > minimum posting size, no need
> > > to undergo vq reset.
> > > > If merged buffer is not done, and buffer posted are smaller than new mtu,
> > > undergo vq reset optionally.
> > > 
> > > This can be done with or without sending mtu to device.
> > Yes, telling mtu to device helps device to optimize and adhere to the spec line " The device MUST NOT pass received packets that exceed mtu" in section 5.1.4.1.
> 
> Again, that line refers to \field{mtu} which is the max mtu supported,
> irrespective to anything driver does.

BTW with any such ctrl vq interface we need to think how cases such as
increasing and decreasing MTU work.  The normal behaviour for linux
drivers is to limit this to when the link is down.  Which reminds me, we
do not have a command to bring link down, either.

> -- 
> MST

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2022-08-10 17:02 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220802044548.9031-1-gavinl@nvidia.com>
2022-08-04  5:00 ` [virtio-dev] [PATCH] virtio-net: use mtu size as buffer length for big packets Jason Wang
2022-08-04  7:10   ` Michael S. Tsirkin
2022-08-04  7:23     ` Jason Wang
2022-08-04  7:24       ` Jason Wang
2022-08-05 22:11 ` Si-Wei Liu
2022-08-05 23:26   ` Si-Wei Liu
     [not found]   ` <c4c42174-dcf0-b1e1-a483-0447fbdb1c48@nvidia.com>
2022-08-08 23:56     ` Si-Wei Liu
     [not found]       ` <465efc4c-f41f-494e-8f2d-a87deae90c5d@nvidia.com>
2022-08-09  7:44         ` Jason Wang
2022-08-09  9:22           ` Michael S. Tsirkin
2022-08-09  9:28             ` Jason Wang
2022-08-09  9:25           ` Michael S. Tsirkin
2022-08-09  9:40             ` Jason Wang
2022-08-09 18:38           ` Si-Wei Liu
2022-08-09 18:42             ` Parav Pandit via Virtualization
2022-08-09 19:08               ` Si-Wei Liu
2022-08-09 19:18                 ` Parav Pandit via Virtualization
2022-08-09 20:32                   ` Si-Wei Liu
2022-08-09 21:13                     ` Parav Pandit via Virtualization
2022-08-09 21:32                       ` Michael S. Tsirkin
2022-08-09 21:37                   ` Michael S. Tsirkin
2022-08-09 21:49                     ` Parav Pandit via Virtualization
2022-08-09 22:25                       ` Michael S. Tsirkin
2022-08-09 22:49                         ` Parav Pandit via Virtualization
2022-08-09 22:59                           ` Michael S. Tsirkin
2022-08-09 23:04                           ` Michael S. Tsirkin
2022-08-09 23:24                           ` Si-Wei Liu
2022-08-10  6:14                             ` Michael S. Tsirkin
2022-08-10  6:15                               ` Michael S. Tsirkin
2022-08-10  6:59                                 ` Jason Wang
2022-08-10  9:03                                   ` Michael S. Tsirkin
2022-08-10 16:00                                     ` Parav Pandit via Virtualization
2022-08-10 16:05                                       ` Michael S. Tsirkin
2022-08-10 16:22                                         ` Parav Pandit via Virtualization
2022-08-10 16:58                                           ` Michael S. Tsirkin
2022-08-10 17:02                                             ` Michael S. Tsirkin [this message]
2022-08-10 17:06                                             ` Parav Pandit via Virtualization
2022-08-10 17:12                                               ` Michael S. Tsirkin
2022-08-11  0:26                                 ` Si-Wei Liu
2022-08-09 22:32                     ` Si-Wei Liu
2022-08-09 22:37                       ` Michael S. Tsirkin
2022-08-09 22:54                         ` Si-Wei Liu
2022-08-09 23:03                           ` Michael S. Tsirkin
2022-08-10  1:24                           ` Jason Wang
2022-08-09 21:34             ` Michael S. Tsirkin
2022-08-09 21:39               ` Si-Wei Liu
2022-08-09 22:27                 ` Michael S. Tsirkin
2022-08-10  1:15             ` Jason Wang
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=20220810125935-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=jesse.brandeburg@intel.com \
    --cc=kubakici@wp.pl \
    --cc=loseweigh@gmail.com \
    --cc=parav@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox