From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0079.outbound.protection.outlook.com [104.47.32.79]) by dpdk.org (Postfix) with ESMTP id EEEF22BA4 for ; Tue, 27 Sep 2016 17:41:10 +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=2vgGU7j1Jq7MF83+x42rFq7Ui3742A7oxSjeSiwWiSE=; b=LVvvm6ZQIoVY0YbjWfYFFkr8DhYxvepS/1XBkW5toyU5Fy3cDCL6QVQe6kr4abUmThTF1XimBmcvSPl/99I08UvQNSNwK+Ram1CmU1blx2kk/c1s9cs7OIWUt3VhGudHMA2ebVHyxqlIKeUTLeUBnZsbxB1LSWQ5ruvo+f2I3bc= Received: from BN3PR03MB1494.namprd03.prod.outlook.com (10.163.35.145) by BN3PR03MB1494.namprd03.prod.outlook.com (10.163.35.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Tue, 27 Sep 2016 15:41:07 +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.0639.013; Tue, 27 Sep 2016 15:41:07 +0000 From: "Dey, Souvik" To: Yuanhan Liu , Stephen Hemminger CC: "Kavanagh, Mark B" , "dev@dpdk.org" Thread-Topic: [PATCH v6] net/virtio: add set_mtu in virtio Thread-Index: AQHSFF2bGYWatJTFW0SUpX36+50+dKCElTyAgAALYiCAAByIgIAB+TgAgAAUygCAAGPKUIAD8nYAgAJg3WA= Date: Tue, 27 Sep 2016 15:41:07 +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> <20160926032128.GH23158@yliu-dev.sh.intel.com> In-Reply-To: <20160926032128.GH23158@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: [208.45.178.4] x-ms-office365-filtering-correlation-id: 803c8dca-52b2-495b-c654-08d3e6ecb305 x-microsoft-exchange-diagnostics: 1; BN3PR03MB1494; 6:2xNGznKJTSuCtJ2pOrfoXyy4sQduWSYaIox9EQbnYODFaIzsHac9aiqybR9jVGV/Nyf9/vqMX2Quxg7YMYhDHNkwXQmfilegKRndQEX9by1hlfVQPEG0N3worNOCg55fMRastmOXI7GpAtZI/ekiR6UMuD1VtFCnmqUUONemdhKDk55jR1d3/66f5hPNPA+VJLirQhEE2RaCygqFeATH5GTpbNRxG34RP5JUn95WEKQns8LErAaQK3TQTQyNm5HAWnzc2Y+MOmGL6EIUoFUH7BVrO8fAfgMc3kFCnkqBDDg=; 5:PmeDJN93+p3Ciw5usHoWFhpPod8QMQ5eHSH7IzBwwmMPMcBKf5BCHutc4m8nw0VGnWTTyumm4TsVZpTnKXEJ0zODPhBp58YHjpQp8RBfHajeEa8rgnG/PRl7LMPTO/ZBsI5QHN4+l1B2fK0twv/tnQ==; 24:/XBaI6hXRpNl1v3WBXNP+/TQPqUljn6xFLCqc4WgRUZJinqRaErNFd0E9tMeg622n+NrOef1iNY05PSMbeyzyS/2YqQ2DTmBBS0guTfx7Wc=; 7:PGZgbB5dFxmXanM8yeRJKE87Ojv5uEFWuargBsi6xOlBQwgkWmYQPnqLgMeA2ZYHd8ji08HJ8MKnPnnJFByreRCVT9z8lxUaDFJm6Eoxgcopa25t6INo50LcjODEBuFPgutIhg7WBcZqvqa+9O1cLLUGQeAlylQt4YH66rEEQfcWk48O0HxyfIrFMeyBz0P4XqK9OSERJA6pn58RTU8SXbKlSJkKe1qYrDDR4YfmUXE3iLByMjNShqzqvGFNxCLl6wZhTJ4DQ42p4Q6i61lZNsokynKVduhEn/68f1npwkt8Omq0jiNEtzd02kSPkLu+ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1494; 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)(3002001)(10201501046); SRVR:BN3PR03MB1494; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1494; x-forefront-prvs: 007814487B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377454003)(24454002)(13464003)(189002)(53754006)(199003)(122556002)(86362001)(106116001)(106356001)(54356999)(19580405001)(19580395003)(76176999)(50986999)(93886004)(7846002)(7736002)(101416001)(66066001)(5001770100001)(105586002)(99286002)(97736004)(74316002)(305945005)(81166006)(8676002)(81156014)(11100500001)(33656002)(10400500002)(4326007)(189998001)(5002640100001)(92566002)(77096005)(2950100002)(9686002)(87936001)(2906002)(2900100001)(3280700002)(76576001)(6116002)(586003)(68736007)(8936002)(3846002)(102836003)(5660300001)(3660700001)(7696004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR03MB1494; H:BN3PR03MB1494.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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: 27 Sep 2016 15:41:07.7830 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1494 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: Tue, 27 Sep 2016 15:41:11 -0000 Hi All, Any further updates/comments on this ? -- Regards, Souvik -----Original Message----- From: Yuanhan Liu [mailto:yuanhan.liu@linux.intel.com]=20 Sent: Sunday, September 25, 2016 11:21 PM To: Stephen Hemminger Cc: Dey, Souvik ; Kavanagh, Mark B ; dev@dpdk.org Subject: Re: [PATCH v6] net/virtio: add set_mtu in virtio Hi Stephen, Are you okay with this change? --yliu On Fri, Sep 23, 2016 at 03:17:37PM +0000, Dey, Souvik wrote: > Hi Liu/Mark/Stephen, >=20 > I have tried to modify the code with all of your latest com= ments. > 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/=20 > 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=20 > 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 virtio_eth_dev_ops=20 > =3D { >=20 > .allmulticast_enable =3D virtio_dev_allmulticast_enable, >=20 > .allmulticast_disable =3D virtio_dev_allmulticast_disable= , >=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 >=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 >=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: 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=20 > >> > > +mtu) { >=20 > >> > > + struct rte_eth_dev_info dev_info; >=20 > >> > > + uint32_t ether_hdr_len =3D ETHER_HDR_LEN + ETHER_CRC_LEN=20 > >> > > + + > 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 >=20 > >> > > + dev_info.max_rx_pktlen) > { >=20 > >> > > + PMD_INIT_LOG(ERR, "MTU should be between %d and=20 > >> > > + %d\n", >=20 > >> > > + ETHER_MIN_MTU, >=20 > >> > > + (dev_info.max_rx_pktlen - > 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 all=20 > >> > 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 will >=20 > >keep the changes future proof. As we need to support till 65535=20 > >instead of > 9728 as the linux does. >=20 > >>=20 >=20 > >> Fine, then just dereference hw->rx_max_pktlen. Driver code=20 > >> can/should >=20 > >> reference its own data directly. >=20 > >=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 > >> > >=20 > >> > 2. Defining VLAN_TAG_SIZE is irrelevant if doing vlan offload. >=20 > >> > [Dey, Souvik] vlan offload is not mandatory. Se again still have >=20 > >> > vlan being sent up to >=20 > >the application. In that case we need to consider the vlan length in=20 > >the > Ethernet size. >=20 > >>=20 >=20 > >> The code needs to handle both vlan offload (or not), correctly. You >=20 > >> are assuming the worst case here. >=20 > >=20 >=20 > >I think we are fine here to assume worst case. >=20 > >=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=20 > >> > consider > this length too. >=20 > >Mark what do you suggest ? >=20 > >>=20 >=20 > >> Actually, the thing that matters is the size of the merge rx buf=20 > >> header, not > the CRC. >=20 > >=20 >=20 > >Right. >=20 > =20 >=20 > My comments were based on my experience with DPDK ethdev PMDs -=20 > Stephen and Yuanhan have much more experience with virtio, so I'd go with= their suggestion. >=20 > =20 >=20 > >=20 >=20 > > --yliu >=20 > >>=20 >=20 > >> The patch is still buggy. >=20 > >>=20 >=20