From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 849FB1B7E7 for ; Tue, 5 Jun 2018 13:20:17 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jun 2018 04:20:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,478,1520924400"; d="scan'208";a="45389444" Received: from debian.sh.intel.com (HELO debian) ([10.67.104.203]) by fmsmga008.fm.intel.com with ESMTP; 05 Jun 2018 04:20:15 -0700 Date: Tue, 5 Jun 2018 19:20:29 +0800 From: Tiwei Bie To: Maxime Coquelin Cc: zhihong.wang@intel.com, dev@dpdk.org Message-ID: <20180605112029.GA27423@debian> References: <20180601124758.22652-1-maxime.coquelin@redhat.com> <20180601124758.22652-5-maxime.coquelin@redhat.com> <20180604115507.GA21406@debian> <5b8d8122-5521-2f65-51e8-224f49f8fb57@redhat.com> <20180605031057.GA5404@debian> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.5 (2018-04-13) Subject: Re: [dpdk-dev] [PATCH 4/4] net/virtio: improve offload check performance X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 11:20:17 -0000 On Tue, Jun 05, 2018 at 11:43:11AM +0200, Maxime Coquelin wrote: > On 06/05/2018 05:10 AM, Tiwei Bie wrote: > > On Mon, Jun 04, 2018 at 04:29:56PM +0200, Maxime Coquelin wrote: > > > On 06/04/2018 01:55 PM, Tiwei Bie wrote: > > > > On Fri, Jun 01, 2018 at 02:47:58PM +0200, Maxime Coquelin wrote: > > [...] > > > > > @@ -253,13 +246,15 @@ virtqueue_enqueue_xmit(struct virtnet_tx *txvq, struct rte_mbuf *cookie, > > > > > struct virtio_net_hdr *hdr; > > > > > int offload; > > > > > - offload = tx_offload_enabled(vq->hw); > > > > > head_idx = vq->vq_desc_head_idx; > > > > > idx = head_idx; > > > > > dxp = &vq->vq_descx[idx]; > > > > > dxp->cookie = (void *)cookie; > > > > > dxp->ndescs = needed; > > > > > + offload = vq->hw->has_tx_offload && > > > > > + (cookie->ol_flags & PKT_TX_OFFLOAD_MASK); > > > > > > > > If features aren't negotiated, I think there is no need to > > > > check ol_flags and update the net header. > > > > > > Isn't what the code is doing? > > > has_tx_offload will be false if none of the Tx offload features have > > > been negotiated, so ol_flags won't be checked in that case. > > > > Hmm.. Somehow I treated 'and' as 'or'.. > > > > I have another question. When 'can_push' is false > > and 'vq->hw->has_tx_offload' is true, there will > > be a chance that virtio net hdr won't be zeroed > > when ol_flags doesn't specify any Tx offloads. > > Right, good catch. > It may be better to remove this small optimization. > Indeed, with the series, if the application does not enable offloads, > then the Virtio features are re-negotiated with the offload features. Yeah. It's a good idea to disable the features when the corresponding Tx offloads aren't requested by the applications! I like it! This issue happens for the mbufs whose ol_flags doesn't specify Tx offloads when applications enable Tx offloads and can_push is false. I think when applications enable Tx offloads, although most packets to be sent will have Tx offloads specified in their ol_flags, it's still possible that some packets don't have Tx offloads specified in their ol_flags. Best regards, Tiwei Bie > > Thanks, > Maxime > > > Best regards, > > Tiwei Bie > >