From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <jfreimann@redhat.com>
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
by dpdk.org (Postfix) with ESMTP id CC4421B45A;
Thu, 31 Jan 2019 17:33:31 +0100 (CET)
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com
[10.5.11.13])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.redhat.com (Postfix) with ESMTPS id 0CC96CFC5;
Thu, 31 Jan 2019 16:33:31 +0000 (UTC)
Received: from localhost (unknown [10.36.118.114])
by smtp.corp.redhat.com (Postfix) with ESMTPS id DB5A5608C8;
Thu, 31 Jan 2019 16:33:26 +0000 (UTC)
Date: Thu, 31 Jan 2019 17:33:25 +0100
From: Jens Freimann <jfreimann@redhat.com>
To: Ilya Maximets <i.maximets@samsung.com>
Cc: dev@dpdk.org, tiwei.bie@intel.com, maxime.coquelin@redhat.com,
stable@dpdk.org
Message-ID: <20190131163325.glu2x7nqogn4d5y7@jenstp.localdomain>
References: <20190131091736.14844-1-jfreimann@redhat.com>
<CGME20190131110154eucas1p150b171c1c77a49e12843d28b61116966@eucas1p1.samsung.com>
<2cb3d89b-5fe4-735c-2dc9-62ba49d305f2@samsung.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <2cb3d89b-5fe4-735c-2dc9-62ba49d305f2@samsung.com>
User-Agent: NeoMutt/20180716
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16
(mx1.redhat.com [10.5.110.30]); Thu, 31 Jan 2019 16:33:31 +0000 (UTC)
Subject: Re: [dpdk-stable] [v3] net/virtio: set offload flag for jumbo frames
X-BeenThere: stable@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches for DPDK stable branches <stable.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/stable>,
<mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/stable>,
<mailto:stable-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Jan 2019 16:33:32 -0000
On Thu, Jan 31, 2019 at 02:01:53PM +0300, Ilya Maximets wrote:
>On 31.01.2019 12:17, Jens Freimann wrote:
>> Port configuration fails because offload flags don't match the expected
>> value when max-pkt-len is set to a value that should enable receive port
>> offloading but doesn't.
>>
>> There are two cases to consider:
>>
>> 1. VIRTIO_NET_F_MTU is set. Then we need to check if the requested
>> max-pkt-len fits into the MTU plus header. If yes we set the
>> offload flag.
>> 2. VIRTIO_NET_F_MTU is not set. We can set the offload flag.
>>
>> Fixes: a4996bd89c42 ("ethdev: new Rx/Tx offloads API")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Jens Freimann <jfreimann@redhat.com>
>> Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
>> ---
>> v2->v3:
>> * remove unnecessary brackets (Maxime)
>> * fix commit message (David)
>>
>> v1->v2:
>> * include virtnet hdr, ethernet header, vlan tag when comparing against
>> max-rx-pkt-len (Maxime)
>>
>> drivers/net/virtio/virtio_ethdev.c | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
>> index 7c4c1df00..f39d4e630 100644
>> --- a/drivers/net/virtio/virtio_ethdev.c
>> +++ b/drivers/net/virtio/virtio_ethdev.c
>> @@ -2351,6 +2351,20 @@ virtio_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
>> if ((host_features & tso_mask) == tso_mask)
>> dev_info->rx_offload_capa |= DEV_RX_OFFLOAD_TCP_LRO;
>>
>> + if (host_features & (1ULL << VIRTIO_NET_F_MTU)) {
>> + struct virtio_net_config config;
>> + uint32_t ether_hdr_len = ETHER_HDR_LEN + VLAN_TAG_LEN +
>> + hw->vtnet_hdr_size;
>> + vtpci_read_dev_config(hw,
>> + offsetof(struct virtio_net_config, mtu),
>> + &config.mtu, sizeof(config.mtu));
>> + if (dev->data->dev_conf.rxmode.max_rx_pkt_len <=
>> + config.mtu + ether_hdr_len)
>> + dev_info->rx_offload_capa |= DEV_RX_OFFLOAD_JUMBO_FRAME;
>> + } else {
>> + dev_info->rx_offload_capa |= DEV_RX_OFFLOAD_JUMBO_FRAME;
>> + }
>> +
>
>Why we can't just use 'hw->max_mtu' here for checking instead of
>reading 'config.mtu' ?
>Also, It's already calculated with regards to VIRTIO_NET_F_MTU.
Can't mtu have changed after device init? If not then yes, I guess we
could use hw->max_mtu.
regards,
Jens