From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luca Boccassi Subject: Re: [PATCH 2/2] ethdev: pre-emptively document rte_eth_dev_reset error code Date: Thu, 19 Oct 2017 17:14:19 +0100 Message-ID: <1508429659.31273.2.camel@debian.org> References: <20171019134827.22740-1-luca.boccassi@gmail.com> <20171019134827.22740-2-luca.boccassi@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: wenzhuo.lu@intel.com, wei.dai@intel.com To: Remy Horton , dev@dpdk.org Return-path: Received: from mail-wr0-f193.google.com (mail-wr0-f193.google.com [209.85.128.193]) by dpdk.org (Postfix) with ESMTP id 3CECA1B252 for ; Thu, 19 Oct 2017 18:14:21 +0200 (CEST) Received: by mail-wr0-f193.google.com with SMTP id o44so8872713wrf.11 for ; Thu, 19 Oct 2017 09:14:21 -0700 (PDT) In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, 2017-10-19 at 15:53 +0100, Remy Horton wrote: > On 19/10/2017 14:48, luca.boccassi@gmail.com wrote: > > Document it immediately even if it's not yet supported, so that > > users > > and developers can already take into account about this use case, > > and > > thus avoid an API-incompatible change later on. >=20 > I'm not sure about documenting unimplemented features, as API docs > ought=C2=A0 > to describe what the code currently does. Then again reason seems OK > and=C2=A0 > I don't think there's hard guidelines on this.. Yeah I realised that, that's why it's a separate patch :-) I'm just trying to avoid a foreseeable API breakage given we've been using this API in production. OTOH there are a few cases where perhaps EAGAIN is already a possible error code to return - for example where the driver fails to initialise? For example there's an error path that just returns -1 in i40evf_dev_init > > This is based on real-world production usage and customer > > escalations, > > using earlier patches from Intel. >=20 > Can you give the patchwork link for these patches? >=20 >=20 > ..Remy Based on these ones: http://dpdk.org/dev/patchwork/patch/14009/ http://dpdk.org/dev/patchwork/patch/14011/ http://dpdk.org/dev/patchwork/patch/14010/ I had sent some feedback, as especially the ixgbe one was a blocking call in case the PF was down, which is a deal breaker in most situations given the API will be called from the controller thread in most cases. We've adapted and used these patches with the early rte_eth_dev_reset for a year in production now, and we had a customer who requested it since they were running into the problem it solves (PF flaps). I have adapted them on the latest 17.11 tree and tested with X540 10gbit cards, and it seems to work as before. Should I send an RFC and CC all of you? Incidentally, are there specific reasons why the VF functionality was dropped since the first patches were sent? --=20 Kind regards, Luca Boccassi