From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id F17D71B39A for ; Wed, 30 Jan 2019 17:12:54 +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 5052B13822F; Wed, 30 Jan 2019 16:12:54 +0000 (UTC) Received: from localhost (dhcp-192-225.str.redhat.com [10.33.192.225]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E71C6608C6; Wed, 30 Jan 2019 16:12:51 +0000 (UTC) Date: Wed, 30 Jan 2019 17:12:50 +0100 From: Jens Freimann To: Maxime Coquelin Cc: dev@dpdk.org, tiwei.bie@intel.com Message-ID: <20190130161250.naw5zicz3hhvkca6@jenstp.localdomain> References: <20190130152634.8652-1-jfreimann@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: 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.38]); Wed, 30 Jan 2019 16:12:54 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH] net/virtio: set offload flag for jumbo frames 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: Wed, 30 Jan 2019 16:12:55 -0000 On Wed, Jan 30, 2019 at 04:41:55PM +0100, Maxime Coquelin wrote: > > >On 1/30/19 4:26 PM, Jens Freimann wrote: >>Port configuration fails when offload flags don't match the expected >>value, e.g. when max-pkt-len is set to a value that should enable >>receive port offloading but doesn't. >> >>This can be triggered by running testpmd e.g. with --max-pkt-len=2000. >>It will fail with "Ethdev port_id=0 requested Rx offloads 0x800 doesn't >>match Rx offloads capabilities 0x20d in rte_eth_dev_configure()" >> >>To fix this there are two cases to consider: >> >>1. VIRTIO_NET_F_MTU is negotiated. Then we need to check if the >> requested max. packet length fits into the MTU. If yes we set the >> offload flag. >>2. VIRTIO_NET_F_MTU is not negotiated. We can set the offload flag. > >I think we need to Cc: stable and point to the commit introducing the >regression. I think it is the one introducing the use of >DEV_RX_OFFLOAD_JUMBO_FRAME in Virtio PMD. ok >> >>Signed-off-by: Jens Freimann >>--- >> drivers/net/virtio/virtio_ethdev.c | 11 +++++++++++ >> 1 file changed, 11 insertions(+) >> >>diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c >>index 7c4c1df00..e0d6542d4 100644 >>--- a/drivers/net/virtio/virtio_ethdev.c >>+++ b/drivers/net/virtio/virtio_ethdev.c >>@@ -2351,6 +2351,17 @@ 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; >>+ 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) > >That is not exactly right, MTU does not take into account the Ethernet >header, the VLAN tag and the virtio-net header. > >See virtio_mtu_set() for example. I wasn't sure about it, will send a v2. Thanks for the review! regards, Jens