All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Parri <parri.andrea@gmail.com>
To: Yanming Liu <yanminglr@gmail.com>
Cc: linux-hyperv@vger.kernel.org,
	Andres Beltran <lkmlabelt@gmail.com>,
	Dexuan Cui <decui@microsoft.com>, Wei Liu <wei.liu@kernel.org>,
	Stephen Hemminger <sthemmin@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	Michael Kelley <mikelley@microsoft.com>
Subject: Re: [PATCH] hv: account for packet descriptor in maximum packet size
Date: Tue, 14 Dec 2021 22:36:59 +0100	[thread overview]
Message-ID: <20211214213659.GA2550@anparri> (raw)
In-Reply-To: <CAH+BkoE51_zAtgOo5ZGJk+32cycQ+OetL_U8hyO8oNMJaymAGg@mail.gmail.com>

> Thank you for your very detailed reply! I'm going to send a V2 which
> should address all your comments.

Appreciated.  (Well, it might be worth to give other people/reviewers
some more time to process v1 and this discussion...  ;) )


> Provided that there are indeed drivers (hv_storvsc and hv_netvsc)
> which explicitly account for vmpacket_descriptor header, changing
> max_pkt_size for individual drivers makes more sense.
> However in this case I'm not sure about our reasoning of 'pkt_offset'
> above. In drivers/scsi/storvsc_drv.c:
> 
> #define STORVSC_MAX_PKT_SIZE (sizeof(struct vmpacket_descriptor) +\
>                               sizeof(struct vstor_packet))
> 
> Should I also change this 'sizeof(struct vmpacket_descriptor)' to
> VMBUS_MAX_PKT_DESCR_SIZE? Otherwise this would not match the check in
> hv_pkt_iter_first.

AFAICT, the above #define is fine, i.e., it represents an upper bound
on pkt_len as used in hv_pkt_iter_first() (this is all is required on
max_pkt_size, cf. the memcpy() in hv_pkt_iter_first()).

The same consideration, AFAICT, holds for NETVSC_MAX_PKT_SIZE.

The remarks about pkt_offset targetted the cases, such as hv_balloon,
where we can somehow upper bound

	(pkt_len - pkt_offset)

(the "packet payload"), since then an upper bound on pkt_offset would
give us an upper bound on pkt_len "for free" (associativity):

	ptk_len = (pkt_len - pkt_offset) + pkt_offset

  Andrea

  reply	other threads:[~2021-12-14 21:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-12 12:13 [PATCH] hv: account for packet descriptor in maximum packet size Yanming Liu
2021-12-13  1:47 ` Andrea Parri
2021-12-13  6:44   ` Yanming Liu
2021-12-13 17:01   ` Yanming Liu
2021-12-14  2:06     ` Andrea Parri
2021-12-14  4:28       ` Andrea Parri
2021-12-14 16:28         ` Yanming Liu
2021-12-14 21:36           ` Andrea Parri [this message]
2021-12-15 12:30             ` Yanming Liu
2021-12-15 14:05               ` Andrea Parri

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=20211214213659.GA2550@anparri \
    --to=parri.andrea@gmail.com \
    --cc=decui@microsoft.com \
    --cc=haiyangz@microsoft.com \
    --cc=kys@microsoft.com \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=lkmlabelt@gmail.com \
    --cc=mikelley@microsoft.com \
    --cc=sthemmin@microsoft.com \
    --cc=wei.liu@kernel.org \
    --cc=yanminglr@gmail.com \
    /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.