From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 3E0CF5680 for ; Thu, 10 Sep 2015 01:03:59 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga101.fm.intel.com with ESMTP; 09 Sep 2015 16:03:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,499,1437462000"; d="scan'208";a="801221945" Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86]) by orsmga002.jf.intel.com with ESMTP; 09 Sep 2015 16:03:57 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 10 Sep 2015 07:03:56 +0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.206]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.182]) with mapi id 14.03.0224.002; Thu, 10 Sep 2015 07:03:54 +0800 From: "Ouyang, Changchun" To: "Liu, Jijiang" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [RFC PATCH 4/8] driver/virtio:enqueue TSO offload Thread-Index: AQHQ49FyY8E0km17CkSfqe/fCvpK4Z4nA8qwgAkWg4CAA1bukIAAiNcAgADj8bA= Date: Wed, 9 Sep 2015 23:03:54 +0000 Message-ID: References: <1441014108-3125-1-git-send-email-jijiang.liu@intel.com> <1441014108-3125-5-git-send-email-jijiang.liu@intel.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC057D986D@SHSMSX101.ccr.corp.intel.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC057DAD0D@SHSMSX101.ccr.corp.intel.com> In-Reply-To: <1ED644BD7E0A5F4091CF203DAFB8E4CC057DAD0D@SHSMSX101.ccr.corp.intel.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC PATCH 4/8] driver/virtio:enqueue TSO offload 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, 09 Sep 2015 23:04:00 -0000 > -----Original Message----- > From: Liu, Jijiang > Sent: Thursday, September 10, 2015 1:21 AM > To: Ouyang, Changchun; dev@dpdk.org > Subject: RE: [dpdk-dev] [RFC PATCH 4/8] driver/virtio:enqueue TSO offload >=20 >=20 >=20 > > -----Original Message----- > > From: Ouyang, Changchun > > Sent: Tuesday, September 8, 2015 6:18 PM > > To: Liu, Jijiang; dev@dpdk.org > > Cc: Ouyang, Changchun > > Subject: RE: [dpdk-dev] [RFC PATCH 4/8] driver/virtio:enqueue TSO > > offload > > > > > > > > > -----Original Message----- > > > From: Liu, Jijiang > > > Sent: Monday, September 7, 2015 2:11 PM > > > To: Ouyang, Changchun; dev@dpdk.org > > > Subject: RE: [dpdk-dev] [RFC PATCH 4/8] driver/virtio:enqueue TSO > > > offload > > > > > > > > > > > > > -----Original Message----- > > > > From: Ouyang, Changchun > > > > Sent: Monday, August 31, 2015 8:29 PM > > > > To: Liu, Jijiang; dev@dpdk.org > > > > Cc: Ouyang, Changchun > > > > Subject: RE: [dpdk-dev] [RFC PATCH 4/8] driver/virtio:enqueue TSO > > > > offload > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jijiang Liu > > > > > Sent: Monday, August 31, 2015 5:42 PM > > > > > To: dev@dpdk.org > > > > > Subject: [dpdk-dev] [RFC PATCH 4/8] driver/virtio:enqueue TSO > > > > > offload > > > > > > > > > > Enqueue TSO4/6 offload. > > > > > > > > > > Signed-off-by: Jijiang Liu > > > > > --- > > > > > drivers/net/virtio/virtio_rxtx.c | 23 +++++++++++++++++++++++ > > > > > 1 files changed, 23 insertions(+), 0 deletions(-) > > > > > > > > > > diff --git a/drivers/net/virtio/virtio_rxtx.c > > > > > b/drivers/net/virtio/virtio_rxtx.c > > > > > index c5b53bb..4c2d838 100644 > > > > > --- a/drivers/net/virtio/virtio_rxtx.c > > > > > +++ b/drivers/net/virtio/virtio_rxtx.c > > > > > @@ -198,6 +198,28 @@ virtqueue_enqueue_recv_refill(struct > > > > > virtqueue *vq, struct rte_mbuf *cookie) > > > > > return 0; > > > > > } > > > > > > > > > > +static void > > > > > +virtqueue_enqueue_offload(struct virtqueue *txvq, struct > > > > > +rte_mbuf > > > *m, > > > > > + uint16_t idx, uint16_t hdr_sz) { > > > > > + struct virtio_net_hdr *hdr =3D (struct virtio_net_hdr > *)(uintptr_t) > > > > > + (txvq->virtio_net_hdr_addr + idx * > hdr_sz); > > > > > + > > > > > + if (m->tso_segsz !=3D 0 && m->ol_flags & PKT_TX_TCP_SEG) { > > > > > + if (m->ol_flags & PKT_TX_IPV4) { > > > > > + if (!vtpci_with_feature(txvq->hw, > > > > > VIRTIO_NET_F_HOST_TSO4)) > > > > > + return; > > > > > > > > Do we need return error if host can't handle tso for the packet? > > > > > > > > > + hdr->gso_type =3D > VIRTIO_NET_HDR_GSO_TCPV4; > > > > > + } else if (m->ol_flags & PKT_TX_IPV6) { > > > > > + if (!vtpci_with_feature(txvq->hw, > > > > > VIRTIO_NET_F_HOST_TSO6)) > > > > > + return; > > > > > > > > Same as above > > > > > > > > > + hdr->gso_type =3D > VIRTIO_NET_HDR_GSO_TCPV6; > > > > > + } > > > > > > > > Do we need else branch for the case of neither tcpv4 nor tcpv6? > > > > > > > > > + hdr->gso_size =3D m->tso_segsz; > > > > > + hdr->hdr_len =3D m->l2_len + m->l3_len + m->l4_len; > > > > > + } > > > > > +} > > > > > + > > > > > static int > > > > > virtqueue_enqueue_xmit(struct virtqueue *txvq, struct rte_mbuf > > > > > *cookie) { @@ -221,6 +243,7 @@ virtqueue_enqueue_xmit(struct > > > > > virtqueue *txvq, struct rte_mbuf *cookie) > > > > > dxp->cookie =3D (void *)cookie; > > > > > dxp->ndescs =3D needed; > > > > > > > > > > + virtqueue_enqueue_offload(txvq, cookie, idx, head_size); > > > > > > > > If TSO is not enabled in the feature bit, how to resolve here? > > > > > > The TSO enablement check is in the function. > > > > > > If TSO is not enabled, and don't need to fill virtio_net_hdr now. > > > > Here I mean if (m->ol_flags & PKT_TX_TCP_SEG) is true, that is to say, > > the virtio- pmd user expect do tso in vhost or virtio, but the host > > feature bit doesn't support it, then it should handle this case, > > either handle it in virtio pmd, or return error to caller. > > Otherwise the packet with flag tso maybe can't be send out normally. > > Am I right? > Not exactly, if host feature bit doesn't support TSO, and the TSO flag ca= nnot > been set in this function, and then continue processing the packet in hos= t. TSO flag is set by upper level, so it could be set even if host feature bit= doesn't support TSO, You know the other path is also supporting TSO in guest feature bit. Currently the virtio driver can't support TSO, at least we should return er= ror for this possible case. > Now I think it had better return an error, and don't continue processing = this > packet. >=20 > > > > > > > > start_dp =3D txvq->vq_ring.desc; > > > > > start_dp[idx].addr =3D > > > > > txvq->virtio_net_hdr_mem + idx * head_size; > > > > > -- > > > > > 1.7.7.6