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 D66CC271 for ; Wed, 13 Dec 2017 17:06:04 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 08C1C5F7BB; Wed, 13 Dec 2017 16:06:04 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (unknown [10.18.25.61]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 54CC27BA3D; Wed, 13 Dec 2017 16:06:03 +0000 (UTC) From: Aaron Conole To: "Stokes\, Ian" Cc: Jan Scheurich , Matteo Croce , "dev\@openvswitch.org" , "'dev\@dpdk.org'" , "Patil\, Harish" References: <20171116172326.22070-1-mcroce@redhat.com> Date: Wed, 13 Dec 2017 11:06:02 -0500 In-Reply-To: (Ian Stokes's message of "Wed, 13 Dec 2017 12:08:42 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 13 Dec 2017 16:06:04 +0000 (UTC) Subject: Re: [dpdk-dev] [ovs-dev] [PATCH] netdev-dpdk: defer MTU set after interface start 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, 13 Dec 2017 16:06:05 -0000 "Stokes, Ian" writes: >> > The issue only arises with the qede PMD and 67fe6d635193 >> > ("netdev-dpdk: use rte_eth_dev_set_mtu.") >> >> I had some more time to look at this today but this patch will break >> OVS DPDK for existing supported DPDK ports during testing. >> >> I tested with an XL710 and the MTU will fail to apply, the device >> must be stopped before configuration changes can be applied such as >> MTU. See log message below >> >> 2017-11-28T17:13:50Z|00086|dpdk|ERR|i40e_dev_mtu_set(): port 0 must >> be stopped before configuration >> 2017-11-28T17:13:50Z|00087|netdev_dpdk|ERR|Interface dpdk0 MTU >> (1500) setup error: Device or resource busy >> >> Did you come across it in your testing? I guess you didn=E2=80=99t see t= his >> for QEDE pmd. In my case the DPDK devices will simply fail to add to >> the >> bridge. >> >> As is, the patch would not be acceptable as its breaking existing >> functionality. It would have to be reworked to configure for device >> that >> cannot reconfigure when busy. >> >> Thanks >> Ian > > I fully support the original decision to switch to using > rte_dev_set_mtu() in OVS. The prior approach setting max_rx_pkt_len in > rte_eth_dev_configure() was non-portable as that field has no > well-defined semantics and its relation to the MTU size is different > for almost every PMD. > > I had a look at the qede PMD implementation of rte_dev_set_mtu() in > DPDK 17.05 and 17.11. It assumes that the device must be started > because qede_set_mtu() unconditionally stops the device before and > restarts it after changing the MTU value. Given that other PMDs like > i40e don=E2=80=99t accept it after start, there is no possible way OVS ca= n use > rte_dev_set_mtu() that will work with all drivers. > > I think it is a weakness of the rte_ethdev API that it does not > specify clearly when API functions like rte_dev_set_mtu() may be > called. From the documentation of error -EBUSY one can guess that the > intention was to optionally support it when the device is > started. Implicitly one could conclude that it MUST be supported when > the device stopped. That is logical and also what most PMDs do. > > I would say the qede PMD should be fixed. It should accept the > rte_dev_set_mtu() at any time between rte_eth_dev_configure() and > rte_eth_dev_start() (and optionally also after start). > > BR, Jan > > [IS] Thanks for doing this follow up Jan, it=E2=80=99s really valuable in= my opinion. > > It=E2=80=99s definitely something that should be raised to the DPDK commu= nity > as conceivably if there is no set process to follow we could see > varying behavior from PMD device to device. I=E2=80=99m happy to take thi= s and > raise it to the DPDK community. Agreed that the understanding of when/how this setter can be called is confusing. I contacted Harish Patil (who works on that driver for the DPDK side) about this, and think that there's a followup to this thread coming. > Thanks > Ian > > _______________________________________________ > dev mailing list > dev@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev