From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id B1A492952 for ; Fri, 23 Sep 2016 09:52:53 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga103.jf.intel.com with ESMTP; 23 Sep 2016 00:52:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,381,1470726000"; d="scan'208";a="1060876998" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by fmsmga002.fm.intel.com with ESMTP; 23 Sep 2016 00:52:51 -0700 Date: Fri, 23 Sep 2016 15:53:20 +0800 From: Yuanhan Liu To: Stephen Hemminger Cc: "Dey, Souvik" , "mark.b.kavanagh@intel.com" , "dev@dpdk.org" Message-ID: <20160923075320.GY23158@yliu-dev.sh.intel.com> References: <20160921231147.26820-1-sodey@sonusnet.com> <20160921162213.4b79d1ce@xeon-e3> <20160921184505.584367ef@xeon-e3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160921184505.584367ef@xeon-e3> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH v6] net/virtio: add set_mtu in virtio X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 07:52:54 -0000 On Wed, Sep 21, 2016 at 06:45:05PM -0700, Stephen Hemminger wrote: > On Thu, 22 Sep 2016 00:08:38 +0000 > "Dey, Souvik" wrote: > > > Answers inline. > > > > -- > > Regards, > > Souvik > > > > -----Original Message----- > > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > > Sent: Wednesday, September 21, 2016 7:22 PM > > To: Dey, Souvik > > Cc: mark.b.kavanagh@intel.com; yuanhan.liu@linux.intel.com; dev@dpdk.org > > Subject: Re: [PATCH v6] net/virtio: add set_mtu in virtio > > > > On Wed, 21 Sep 2016 19:11:47 -0400 > > Dey wrote: > > > > > > > > + > > > +#define VLAN_TAG_SIZE 4 /* 802.3ac tag (not DMA'd) */ > > > + > > > +static int virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) { > > > + struct rte_eth_dev_info dev_info; > > > + uint32_t ether_hdr_len = ETHER_HDR_LEN + ETHER_CRC_LEN + VLAN_TAG_SIZE; > > > + uint32_t frame_size = mtu + ether_hdr_len; > > > + > > > + virtio_dev_info_get(dev, &dev_info); > > > + > > > + if (mtu < ETHER_MIN_MTU || frame_size > dev_info.max_rx_pktlen) { > > > + PMD_INIT_LOG(ERR, "MTU should be between %d and %d\n", > > > + ETHER_MIN_MTU, > > > + (dev_info.max_rx_pktlen - ether_hdr_len)); > > > + return -EINVAL; > > > + } > > > + return 0; > > > +} > > > > I am fine with the general idea of this patch but: > > 1. Calling virtio_dev_info_get is needlessly wasteful when all you want > > is to access the max packet length. Since max_rx_pktlen is always > > VIRTIO_MAX_RX_PKTLEN, please just use that. > > [Dey, Souvik] I am using the virtio_dev_info_get as in future can/may support the max_rx_pktlen as a variable to be set by the application. This will keep the changes future proof. As we need to support till 65535 instead of 9728 as the linux does. > > Fine, then just dereference hw->rx_max_pktlen. Driver code can/should reference > its own data directly. Dey, maybe you could just use VIRTIO_MAX_RX_PKTLEN here, like what you did in early versions. > > > > 2. Defining VLAN_TAG_SIZE is irrelevant if doing vlan offload. > > [Dey, Souvik] vlan offload is not mandatory. Se again still have vlan being sent up to the application. In that case we need to consider the vlan length in the Ethernet size. > > The code needs to handle both vlan offload (or not), correctly. You are assuming > the worst case here. I think we are fine here to assume worst case. > > > > 3. Virtio doesn't insert CRC, therefore CRC_LEN is irrelevant > > [Dey, Souvik] I am not sure of this. Mark commented earlier to consider this length too. Mark what do you suggest ? > > Actually, the thing that matters is the size of the merge rx buf header, not the CRC. Right. --yliu > > The patch is still buggy. >