From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by dpdk.org (Postfix) with ESMTP id 9CEFE1B31D for ; Mon, 12 Feb 2018 12:23:21 +0100 (CET) Received: by mail-wm0-f42.google.com with SMTP id f71so8941247wmf.0 for ; Mon, 12 Feb 2018 03:23:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ma66ij73CL1ToMD2AFi+kohwKuqj0+mTYKTLve71dVs=; b=eqSCzEYohnmISWBhg35l+Gw6qiK7kFoXNtgobT2K0QKyFONnDXH6JX5SMUW0Jpq7/6 graC6kNLDm98bsW48/cUmM7VtR5AKyZeJWk0djtxXRoNxCj5oTmoQjxqXp+T3u6JkRP4 lE0mSZcA55OSgUlV2gGgxndFBBCQoXi9VCZH22WfTJc6rJYHZ57hYb5FQhFWawItvZot Nrgl4MoKCjPckxT2wBo2geGnLtpyXlVeMVZkzhNcy/0yyvBT1AZ9M9kqxiE6nIp4xdM5 MqmGQCTYh0/DHRBLoIqCMqHcuyOzA3VtH3HuITMIlJxmvYPtH4EnGXT8V5P0WymYK7r1 ThCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ma66ij73CL1ToMD2AFi+kohwKuqj0+mTYKTLve71dVs=; b=m5/RODWv6cAidusUMBL+5JuLOOUUp+QGv7+vW2HFibs7cqLjPjJKXWUSbl0rzSaaxv soUdRQxPWrIK+oHqf/J2Lf4vh499xxgRYRJPnTfiIRUl/1GjEXOW4qIRmjllFqbywXTN cwBTKOFIqylj6aJOGYHjA9/5U+Ei6rlQF59AlGxFzIbiFws76TDuyPGAja7gLb63zh9x kCAhUiraLE3Hsh+4mKAJgMroVw3QAxs/7L/whIJIIb/GlblTkaWR1BmvXKJ0kozAC/V/ zO9PO3uW5o8K/nDgLX+TAtZK6pK2tvdT4uF+I/Yz7PKC1f+Lqag+iSHfC8+l/4Z4wugz n6hw== X-Gm-Message-State: APf1xPBC89g7mUrFJUGfMIvhWN7w3nEeBeAlLk/kSjtQxpUKbfdPUIAj 6NWsJV+nCbY8vuCv6E8e0o1Uwg== X-Google-Smtp-Source: AH8x225RUyVvS1UwnjAj2BLR1EcDSK8fCsFe1lZsOzMqnJesbV2uVMuA/B+CtgP9RU4TZmiJtnjukw== X-Received: by 10.28.165.4 with SMTP id o4mr3160760wme.66.1518434601227; Mon, 12 Feb 2018 03:23:21 -0800 (PST) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id l2sm7605769wre.6.2018.02.12.03.23.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Feb 2018 03:23:20 -0800 (PST) Date: Mon, 12 Feb 2018 12:23:07 +0100 From: Adrien Mazarguil To: Thomas Monjalon Cc: Ophir Munk , dev@dpdk.org, Moti Haimovsky , Olga Shern , Matan Azrad , ferruh.yigit@intel.com Message-ID: <20180212112307.GH4256@6wind.com> References: <1518072954-19082-1-git-send-email-ophirmu@mellanox.com> <20180209162124.GD4256@6wind.com> <1944833.dayHpbUbTZ@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1944833.dayHpbUbTZ@xps> Subject: Re: [dpdk-dev] [PATCH v1] doc: update mlx4 flow limitations 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: Mon, 12 Feb 2018 11:23:21 -0000 On Fri, Feb 09, 2018 at 05:39:50PM +0100, Thomas Monjalon wrote: > 09/02/2018 17:21, Adrien Mazarguil: > > This section is titled "Limitations" but contains a mix of features, > > limitations and quirks, more like "Random thoughts regarding rte_flow > > support". I think this is not what users might expect from such a > > documentation which must be exhaustive and consistent. Getting there may > > involve tables. > > +Cc Ferruh > > > My suggestion is to first get everyone agree on a common rte_flow > > capabilities documentation format all PMDs could reuse and then fill in the > > blanks. What's your opinion? > > I think it's better to have some random thoughts than nothing. > All the comments you gave in this thread deserve to be written in > the documentation as soon as possible. Right, but as a side note in the meantime, more complete documentation is already available in Doxygen format in mlx4_flow.c. *All* limitations are also returned in plain text through error messages (rte_flow_error.message) in the same file (git grep 'msg =' drivers/net/mlx4/mlx4_flow.c). While not proper documentation, it shouldn't be too difficult to write an exhaustive list based on that information. > Working on a better standardized documentation (longer term) should > not prevent us to write some messy notes in the meantime. I'm not sure, misleading documentation can do more harm than good for all parties in my opinion, with users assuming features or limitations that do not exist, then making purchase decisions and bug reports based on that. > Is there already some similar rte_flow notes in other PMD docs? I'm not aware of any, but I do think it's a good idea to start with mlx4. > About the common documentation, do you think about a generated table > like it is done for other features? I'm not sure about this specific format, which can be used to deal with a bunch of concrete use cases (e.g. "matching TCPv4 traffic and sending it to some queue = Y") but more than a dozen like that will make it too confusing to be useful. I think the current "Flow API = Y" is enough, the rest should be described in a more verbose format common to all PMDs which remains to be defined. By "tables" I mean coming up with a visual representation for flow attributes, patterns and action lists on a single line such as: +---------+ +-----+------+-----+ +-------+-----+ | ingress | : | ETH | IPV4 | UDP | => | COUNT | RSS | +---------+ +-----+------+-----+ +-------+-----+ And/or some kind of grammar summarizing all the possibilities, e.g. for mlx4: ingress : ETH [ VLAN ] [ IPV4 [ (UDP | TCP) ] ] => [ VOID ] (DROP | QUEUE | RSS) With features/limitation for each item described separately. > Do you plan to provide a template or an example? I certainly would like to submit something with the plan I suggested, unfortunately I don't have time to work on that at the moment. -- Adrien Mazarguil 6WIND