Re: [PATCH] hv: account for packet descriptor in maximum packet size

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux