From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <maxime.coquelin@redhat.com>
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
by dpdk.org (Postfix) with ESMTP id 99B8328F3
for <dev@dpdk.org>; Wed, 5 Oct 2016 15:27:53 +0200 (CEST)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mx1.redhat.com (Postfix) with ESMTPS id 078A050F7A;
Wed, 5 Oct 2016 13:27:52 +0000 (UTC)
Received: from [10.36.6.237] (vpn1-6-237.ams2.redhat.com [10.36.6.237])
by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
u95DRmlS014644
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Wed, 5 Oct 2016 09:27:49 -0400
To: Olivier Matz <olivier.matz@6wind.com>, dev@dpdk.org,
yuanhan.liu@linux.intel.com
References: <1469088510-7552-1-git-send-email-olivier.matz@6wind.com>
<1475485223-30566-1-git-send-email-olivier.matz@6wind.com>
<1475485223-30566-10-git-send-email-olivier.matz@6wind.com>
<1da0b2c2-931b-3164-d211-4ceee7fd6864@redhat.com>
<98db7fbb-42bd-512f-1d40-a1f3304a895e@6wind.com>
Cc: konstantin.ananyev@intel.com, sugesh.chandran@intel.com,
bruce.richardson@intel.com, jianfeng.tan@intel.com,
helin.zhang@intel.com, adrien.mazarguil@6wind.com,
stephen@networkplumber.org, dprovan@bivio.net, xiao.w.wang@intel.com
From: Maxime Coquelin <maxime.coquelin@redhat.com>
Message-ID: <e96537d6-b99a-2668-e8bf-3a64529f0d55@redhat.com>
Date: Wed, 5 Oct 2016 15:27:47 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <98db7fbb-42bd-512f-1d40-a1f3304a895e@6wind.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16
(mx1.redhat.com [10.5.110.30]); Wed, 05 Oct 2016 13:27:53 +0000 (UTC)
Subject: Re: [dpdk-dev] [PATCH v2 09/12] virtio: add Rx checksum offload
support
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Oct 2016 13:27:54 -0000
Hi Olivier,
On 10/05/2016 01:56 PM, Olivier Matz wrote:
> Hi Maxime,
>
> On 10/03/2016 02:51 PM, Maxime Coquelin wrote:
>>> --- a/drivers/net/virtio/virtio_rxtx.c
>>> +++ b/drivers/net/virtio/virtio_rxtx.c
>>> @@ -50,6 +50,7 @@
>>> #include <rte_string_fns.h>
>>> #include <rte_errno.h>
>>> #include <rte_byteorder.h>
>>> +#include <rte_net.h>
>>>
>>> #include "virtio_logs.h"
>>> #include "virtio_ethdev.h"
>>> @@ -627,6 +628,56 @@ virtio_update_packet_stats(struct virtnet_stats
>>> *stats, struct rte_mbuf *mbuf)
>>> }
>>> }
>>>
>>> +/* Optionally fill offload information in structure */
>>> +static int
>>> +virtio_rx_offload(struct rte_mbuf *m, struct virtio_net_hdr *hdr)
>>> +{
>>> + struct rte_net_hdr_lens hdr_lens;
>>> + uint32_t hdrlen, ptype;
>>> + int l4_supported = 0;
>>> +
>>> + /* nothing to do */
>>> + if (hdr->flags == 0 && hdr->gso_type == VIRTIO_NET_HDR_GSO_NONE)
>>> + return 0;
>> Maybe we could first check whether offload features were negotiated?
>> Doing this, we could return before accessing the header and so avoid a
>> cache miss.
>
> Yes, doing this would avoid reading the virtio header when the rx
> function is virtio_recv_pkts(). When using virtio_recv_mergeable_pkts(),
> it won't have a big impact since we already need to read hdr->num_buffers.
Right, it matters only for the non-mergeable buffers case.
>
>
> I plan to do something like this in both recv functions:
>
> @@ -854,6 +854,7 @@ virtio_recv_pkts(void *rx_queue, struct rte_mbuf
> **rx_pkts, uint16_t nb_pkts)
> int error;
> uint32_t i, nb_enqueued;
> uint32_t hdr_size;
> + uint64_t features;
> struct virtio_net_hdr *hdr;
>
> nb_used = VIRTQUEUE_NUSED(vq);
> @@ -872,6 +873,7 @@ virtio_recv_pkts(void *rx_queue, struct rte_mbuf
> **rx_pkts, uint16_t nb_pkts)
> nb_rx = 0;
> nb_enqueued = 0;
> hdr_size = hw->vtnet_hdr_size;
> + features = hw->guest_features;
>
> for (i = 0; i < num ; i++) {
> rxm = rcv_pkts[i];
> @@ -903,7 +905,8 @@ virtio_recv_pkts(void *rx_queue, struct rte_mbuf
> **rx_pkts, uint16_t nb_pkts)
> rte_vlan_strip(rxm);
>
> /* Update offload features */
> - if (virtio_rx_offload(rxm, hdr) < 0) {
> + if ((features & VIRTIO_NET_F_GUEST_CSUM) &&
s/VIRTIO_NET_F_GUEST_CSUM/(1u << VIRTIO_NET_F_GUEST_CSUM)/
And don't forget to update the test for LRO patch.
Except this, it sounds good.
Thanks,
Maxime
> + virtio_rx_offload(rxm, hdr) < 0) {
> virtio_discard_rxbuf(vq, rxm);
> rxvq->stats.errors++;
> continue;
>
> Thank you for the feedback.
> Olivier
>