From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0051.outbound.protection.outlook.com [104.47.40.51]) by dpdk.org (Postfix) with ESMTP id 836F337B4 for ; Wed, 28 Sep 2016 17:31:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=l3eUuo0CsuDTfMN5I9bA3+zFWQaSbhB5S62Uuipt4Ag=; b=knbFyix/0FzmVbb3jVLStPwbxv4JzfWu9yTGDhwspAKqxnEARAGcKtLC8cwHXvTK6Neih/P4gh0PYX2AntcfpvaXPWXiDlIROO2rZZJ6xbP1pldciHzJZt9arS/oA5q99TN1yIm9qmwNVLihusmWAI+NKK6t/Thban0TwnwKYJM= Received: from BN3PR03MB1494.namprd03.prod.outlook.com (10.163.35.145) by BN3PR03MB1495.namprd03.prod.outlook.com (10.163.35.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Wed, 28 Sep 2016 15:31:35 +0000 Received: from BN3PR03MB1494.namprd03.prod.outlook.com ([10.163.35.145]) by BN3PR03MB1494.namprd03.prod.outlook.com ([10.163.35.145]) with mapi id 15.01.0649.016; Wed, 28 Sep 2016 15:31:36 +0000 From: "Dey, Souvik" To: Yuanhan Liu CC: Stephen Hemminger , "Kavanagh, Mark B" , "dev@dpdk.org" Thread-Topic: [PATCH v6] net/virtio: add set_mtu in virtio Thread-Index: AQHSFF2bGYWatJTFW0SUpX36+50+dKCElTyAgAALYiCAAByIgIAB+TgAgAAUygCAAGPKUIAGig4AgAAdHTCAACpAgIABEZoQ Date: Wed, 28 Sep 2016 15:31:35 +0000 Message-ID: References: <20160921231147.26820-1-sodey@sonusnet.com> <20160921162213.4b79d1ce@xeon-e3> <20160921184505.584367ef@xeon-e3> <20160923075320.GY23158@yliu-dev.sh.intel.com> <20160927115634.428d1b7d@xeon-e3> <20160927231159.GA5164@yliu-dev.sh.intel.com> In-Reply-To: <20160927231159.GA5164@yliu-dev.sh.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sodey@sonusnet.com; x-originating-ip: [66.30.138.194] x-ms-office365-filtering-correlation-id: 29465e30-b60a-49a3-e602-08d3e7b48896 x-microsoft-exchange-diagnostics: 1; BN3PR03MB1495; 6:oOSW4/5uqhjzb8fVSdcE1Aqlk2QaUBAay0K3sh69K2neNtfxpTlbXhZg16XE8lE6r1R3vb8iZEhmSTpir8K3WocV8aGy//Bw8FJNq37Crz0bA1wSRriU331DPW5O6To2jdtdMKlx1rmmt7fIFxtOI3uk5ACtnUncYds58/0VSje1eut+6ZoHQPQOgkfjswpFH6yRBWIdbRxjED7YcakidMLaLOscmgBolI23NS3GXuY+6myyZNp1SXeKDHAs6HSkew0Sa8/1hJVSnPu0623ak50GasgI3qdPm59iLpGx0t8=; 5:DJyfyq5OUSM8ut+g45VY6hS6VYLgl5K354LB0UPnARVqf0c+7097G7W7JqkfuaQoUMddHbPvgkAqL61IjndIRnYMQEsa7bfpnAXzR78/GtPDXJamHzA8zdXkcQjP6n5DlWvTsj/jKAPkPTITFMxg3A==; 24:iKwq5p9EArp+mlK5aqrBJNwU0FWsDq+HoiEbXFwnB0cuUq/mdYW2QInXILrIAothlhuvgt8MaoDr4PWOtnIhd9W3qaeQ+WfeTeyTryv6PP4=; 7:L00Bfj//qoTanvQ9s44gpgMh5I+c/ytpt0A1VNgV7VtYI4rwCavRb3xsfi0MRKeM+ZbnFq6i2lGwfnuV1GkBSO13UqGsZ9CR8zk3XUXH2/36sUt9QDOtz4aedr1oODPo9Y7XENqJc3Pt84B74LZpC7k4tsG25QxqpWW+XnXHOcakhWySKqqRcYUww19lCW/gD2PpUJoJop9YDFNd23v7xOYM4ADEa4TgDkR6yiPJRCmny61eAymmu47YBOkp9stM5WTPiab5m6LuFxXxkAVOqNbX7XjEKWG2BQYrP7PunI3O72h34Z61st2rSB6/PDvJ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1495; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN3PR03MB1495; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1495; x-forefront-prvs: 0079056367 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(24454002)(13464003)(377454003)(189002)(19580395003)(19580405001)(106116001)(66066001)(87936001)(93886004)(74316002)(105586002)(305945005)(106356001)(99286002)(9686002)(6916009)(102836003)(3846002)(86362001)(586003)(6116002)(2906002)(2950100002)(68736007)(189998001)(5002640100001)(4326007)(8936002)(97736004)(10400500002)(7846002)(110136003)(3660700001)(101416001)(54356999)(76176999)(3280700002)(92566002)(7696004)(5660300001)(76576001)(33656002)(122556002)(7736002)(77096005)(50986999)(81156014)(81166006)(8676002)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR03MB1495; H:BN3PR03MB1494.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2016 15:31:35.9240 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1495 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: Wed, 28 Sep 2016 15:31:39 -0000 OK sure will do that.=20 -----Original Message----- From: Yuanhan Liu [mailto:yuanhan.liu@linux.intel.com]=20 Sent: Tuesday, September 27, 2016 7:12 PM To: Dey, Souvik Cc: Stephen Hemminger ; Kavanagh, Mark B ; dev@dpdk.org Subject: Re: [PATCH v6] net/virtio: add set_mtu in virtio On Tue, Sep 27, 2016 at 08:44:20PM +0000, Dey, Souvik wrote: > Hi Stephen,=20 > So what should be my next steps , should I submit a v7 for this patch or= you suggest otherwise. Yes, please. Another note is please don't use white space for indentation, = use TAB instead. -yliu >=20 > -- > Regards, > Souvik >=20 > -----Original Message----- > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > Sent: Tuesday, September 27, 2016 2:57 PM > To: Dey, Souvik > Cc: Kavanagh, Mark B ; Yuanhan Liu=20 > ; dev@dpdk.org > Subject: Re: [PATCH v6] net/virtio: add set_mtu in virtio >=20 > On Fri, 23 Sep 2016 15:17:37 +0000 > "Dey, Souvik" wrote: >=20 > > Hi Liu/Mark/Stephen, > >=20 > > I have tried to modify the code with all of your latest c= omments. Do let me know if this looks fine or you have more comments. > >=20 > >=20 > >=20 > > Changes done : > >=20 > > -- max frame ize is compare to VIRTIO_MAX_RX_PKTLEN instead of=20 > > dev_info.max_rx_pktlen > >=20 > > -- removed the CRC_LEN from the ether_len calculation and added the=20 > > merge rx buf hdr len. ether_hdr_len =3D ETHER_HDR_LEN + VLAN_TAG_SIZE=20 > > + > > hw->vtnet_hdr_size > >=20 > > -- Still retained the VLAN Size as the worst case scenario. > >=20 > >=20 > >=20 > >=20 > >=20 > > -- > >=20 > > drivers/net/virtio/virtio_ethdev.c | 16 ++++++++++++++++ > >=20 > > 1 file changed, 16 insertions(+) > >=20 > >=20 > >=20 > > diff --git a/drivers/net/virtio/virtio_ethdev.c > > b/drivers/net/virtio/virtio_ethdev.c > >=20 > > index 423c597..1dbfea6 100644 > >=20 > > --- a/drivers/net/virtio/virtio_ethdev.c > >=20 > > +++ b/drivers/net/virtio/virtio_ethdev.c > >=20 > > @@ -653,12 +653,20 @@ virtio_dev_allmulticast_disable(struct > > rte_eth_dev *dev) > >=20 > > PMD_INIT_LOG(ERR, "Failed to disable allmulticast"); > >=20 > > } > >=20 > >=20 > >=20 > > +#define VLAN_TAG_SIZE 4 /* 802.3ac tag (not DMA'd) */ > >=20 > > + > >=20 > > +static int virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) > >=20 > > +{ > >=20 > > + struct virtio_hw *hw =3D dev->data->dev_private; > >=20 > > + uint32_t ether_hdr_len =3D ETHER_HDR_LEN + VLAN_TAG_SIZE=20 > > + + > > + hw->vtnet_hdr_size; > >=20 > > + uint32_t frame_size =3D mtu + ether_hdr_len; > >=20 > > + > >=20 > > + if (mtu < ETHER_MIN_MTU || frame_size >=20 > > + VIRTIO_MAX_RX_PKTLEN ) { > >=20 > > + PMD_INIT_LOG(ERR, "MTU should be between=20 > > + %d and %d\n", > >=20 > > + ETHER_MIN_MTU,=20 > > + VIRTIO_MAX_RX_PKTLEN); > >=20 > > + return -EINVAL; > >=20 > > + } > >=20 > > + return 0; > >=20 > > +} > >=20 > >=20 > >=20 > > /* > >=20 > > * dev_ops for virtio, bare necessities for basic operation > >=20 > > */ > >=20 > > @@ -677,7 +685,6 @@ static const struct eth_dev_ops=20 > > virtio_eth_dev_ops =3D { > >=20 > > .allmulticast_enable =3D virtio_dev_allmulticast_enabl= e, > >=20 > > .allmulticast_disable =3D virtio_dev_allmulticast_disab= le, > >=20 > > + .mtu_set =3D virtio_mtu_set, > >=20 > > .dev_infos_get =3D virtio_dev_info_get, > >=20 > > .stats_get =3D virtio_dev_stats_get, > >=20 > > .xstats_get =3D virtio_dev_xstats_get, > >=20 > > -- > >=20 > > Please do let me know if this looks good to you all. Thanks > >=20 > >=20 > >=20 > > -- > >=20 > > Regards, > >=20 > > Souvik > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Kavanagh, Mark B [mailto:mark.b.kavanagh@intel.com] > > Sent: Friday, September 23, 2016 5:08 AM > > To: Yuanhan Liu ; Stephen Hemminger=20 > > > > Cc: Dey, Souvik ; dev@dpdk.org > > Subject: RE: [PATCH v6] net/virtio: add set_mtu in virtio > >=20 > >=20 > >=20 > > >Subject: Re: [PATCH v6] net/virtio: add set_mtu in virtio > >=20 > > > > >=20 > > >On Wed, Sep 21, 2016 at 06:45:05PM -0700, Stephen Hemminger wrote: > >=20 > > >> On Thu, 22 Sep 2016 00:08:38 +0000 > >=20 > > >> "Dey, Souvik" > wrote: > >=20 > > >> > >=20 > > >> > Answers inline. > >=20 > > >> > > >=20 > > >> > -- > >=20 > > >> > Regards, > >=20 > > >> > Souvik > >=20 > > >> > > >=20 > > >> > -----Original Message----- > >=20 > > >> > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > >=20 > > >> > Sent: Wednesday, September 21, 2016 7:22 PM > >=20 > > >> > To: Dey, Souvik > > >=20 > > >> > Cc:=20 > > >> > mark.b.kavanagh@intel.com; > > >> > yuanhan.liu@linux.intel.com > > >> > ; > >=20 > > >> > dev@dpdk.org > >=20 > > >> > Subject: Re: [PATCH v6] net/virtio: add set_mtu in virtio > >=20 > > >> > > >=20 > > >> > On Wed, 21 Sep 2016 19:11:47 -0400 > >=20 > > >> > Dey > wrote: > >=20 > > >> > > >=20 > > >> > > > >=20 > > >> > > + > >=20 > > >> > > +#define VLAN_TAG_SIZE 4 /* 802.3ac tag (not DMA'd)= */ > >=20 > > >> > > + > >=20 > > >> > > +static int virtio_mtu_set(struct rte_eth_dev *dev, uint16_t > > >> > > +mtu) { > >=20 > > >> > > + struct rte_eth_dev_info dev_info; > >=20 > > >> > > + uint32_t ether_hdr_len =3D ETHER_HDR_LEN +=20 > > >> > > + ETHER_CRC_LEN > > >> > > + + VLAN_TAG_SIZE; > >=20 > > >> > > + uint32_t frame_size =3D mtu + ether_hdr_len; > >=20 > > >> > > + > >=20 > > >> > > + virtio_dev_info_get(dev, &dev_info); > >=20 > > >> > > + > >=20 > > >> > > + if (mtu < ETHER_MIN_MTU || frame_size > > > >> > > + dev_info.max_rx_pktlen) { > >=20 > > >> > > + PMD_INIT_LOG(ERR, "MTU should be between %d=20 > > >> > > + and %d\n", > >=20 > > >> > > + ETHER_MIN_MTU, > >=20 > > >> > > + (dev_info.max_rx_pktlen -=20 > > >> > > + ether_hdr_len)); > >=20 > > >> > > + return -EINVAL; > >=20 > > >> > > + } > >=20 > > >> > > + return 0; > >=20 > > >> > > +} > >=20 > > >> > > >=20 > > >> > I am fine with the general idea of this patch but: > >=20 > > >> > 1. Calling virtio_dev_info_get is needlessly wasteful when=20 > > >> > all you want > >=20 > > >> > is to access the max packet length. Since max_rx_pktlen is=20 > > >> > always > >=20 > > >> > VIRTIO_MAX_RX_PKTLEN, please just use that. > >=20 > > >> > [Dey, Souvik] I am using the virtio_dev_info_get as in future > >=20 > > >> > can/may support the > >=20 > > >max_rx_pktlen as a variable to be set by the application. This=20 > > >will > >=20 > > >keep the changes future proof. As we need to support till 65535 instea= d of 9728 as the linux does. > >=20 > > >> > >=20 > > >> Fine, then just dereference hw->rx_max_pktlen. Driver code=20 > > >> can/should > >=20 > > >> reference its own data directly. > >=20 > > > > >=20 > > >Dey, maybe you could just use VIRTIO_MAX_RX_PKTLEN here, like what=20 > > >you > >=20 > > >did in early versions. > >=20 > > > > >=20 > > >> > > >=20 > > >> > 2. Defining VLAN_TAG_SIZE is irrelevant if doing vlan offload. > >=20 > > >> > [Dey, Souvik] vlan offload is not mandatory. Se again still=20 > > >> > have > >=20 > > >> > vlan being sent up to > >=20 > > >the application. In that case we need to consider the vlan length in t= he Ethernet size. > >=20 > > >> > >=20 > > >> The code needs to handle both vlan offload (or not), correctly.=20 > > >> You > >=20 > > >> are assuming the worst case here. > >=20 > > > > >=20 > > >I think we are fine here to assume worst case. > >=20 > > > > >=20 > > >> > > >=20 > > >> > 3. Virtio doesn't insert CRC, therefore CRC_LEN is irrelevant > >=20 > > >> > [Dey, Souvik] I am not sure of this. Mark commented earlier to con= sider this length too. > >=20 > > >Mark what do you suggest ? > >=20 > > >> > >=20 > > >> Actually, the thing that matters is the size of the merge rx buf hea= der, not the CRC. > >=20 >=20 > This patch is good enough for now, but not fully correct. > The actual max value depends on the host negotiation protocol, ie merge r= x buf is only sometimes used. >=20 > There was some discussion on netdev mailing list to pass MTU from host to= guest in virtio, not sure where that landed.