From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by dpdk.org (Postfix) with ESMTP id 77A0069C5 for ; Fri, 17 Mar 2017 10:35:02 +0100 (CET) Received: by mail-wm0-f44.google.com with SMTP id v203so7618857wmg.0 for ; Fri, 17 Mar 2017 02:35:02 -0700 (PDT) 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=p8MY01eKPwhqrxWRqncj8Z2H4b8HoZam3ZFaGrWm1Bw=; b=huA787H+rn3yLKo5SrkMknX4q9qlv10oqESZLnFAVVdqe06ZUKGzmYgmupCXrUHmnu axpS9cLrjLYj2NyAGlHXXs4JGMN4nYPYJNMeqrfrIixySbahM9hrY8ybk8dbXqb6YsdV hxHqpeU8jJkM1lMtfPFaDTTwRN8+PjmpjVs37ZCDEISdAn1j+sGNDnCMXlbnnVDHWYHq pPWAuKZxhnwSMGSFsKgr6pZh31we4nQc8wCPHDEd1BIhRVHVPUTF6Clv6WqAs/kB1hAs Y7rUCFmd9fBmLVYvWFfNGY5yggugBcYmcPU94Ya5mY5Gc6MLWs6Pb3bK75+AeBP9PYew VkVA== 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=p8MY01eKPwhqrxWRqncj8Z2H4b8HoZam3ZFaGrWm1Bw=; b=kSaNe9UKn0pw2sEEYB3GDyySxQ1Fm4iKCfIj4et0qdtjp/6ckwowvB7cM0GpdlXsaG s+pO5r+NdL1pZyz43Afg4Wx0xDgrgp7OEmZEVtAaG98Ajbi1a/uj7dxWzQuqM4BIZbbE ktbH7HNpF5KU3fn4EekjsysH3OoY6/VUkvoniuhoYq6CaSgHQXDo5C5mEoXlmSZug/wn YicADBzjBcg+ZMHlgioMYXdqjKy0oqu3QGi5vmxKn60a2jeSEgkyZ4zpHIk7gGLwJsKx 4n6lhyuF8Tih5K2mPlEaSrC/PpF2rsMyyOVrnOUx7nvOi/AgJUhJXL9KmHoswK06Djil AK+A== X-Gm-Message-State: AFeK/H2ZezrrMmpnqS+4ZrmD/R3tpySvBR+3qX6p1U/DuAaxD+wMdhZGQwuEIxR+WqYvwTim X-Received: by 10.28.88.2 with SMTP id m2mr1973275wmb.12.1489743302122; Fri, 17 Mar 2017 02:35:02 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id h5sm2011184wmf.7.2017.03.17.02.35.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Mar 2017 02:35:01 -0700 (PDT) Date: Fri, 17 Mar 2017 10:34:53 +0100 From: Adrien Mazarguil To: Le Scouarnec Nicolas Cc: "Lu, Wenzhuo" , "dev@dpdk.org" Message-ID: <20170317093452.GT3790@6wind.com> References: <20170308154131.GQ3790@6wind.com> <6A0DE07E22DDAD4C9103DF62FEBC09093B56DC90@shsmsx102.ccr.corp.intel.com> <6A0DE07E22DDAD4C9103DF62FEBC09093B56E40A@shsmsx102.ccr.corp.intel.com> <20170310114602.GZ3790@6wind.com> <6A0DE07E22DDAD4C9103DF62FEBC09093B56EDD7@shsmsx102.ccr.corp.intel.com> <20170315105344.GJ3790@6wind.com> <20170315160153.GL3790@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] FW: Issues with ixgbe and rte_flow 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: Fri, 17 Mar 2017 09:35:02 -0000 On Thu, Mar 16, 2017 at 05:01:43PM +0000, Le Scouarnec Nicolas wrote: > > Hi Adrien, > > >On Wed, Mar 15, 2017 at 02:29:44PM +0000, Le Scouarnec Nicolas wrote: > >> Overall, as a user, I feel one difficulty/complexity in using the API comes from the need to > >> specify both the stack of protocol (in type) and at each level the "next protocol type" of the header (in spec). > >> > >> Then, the PMD has to check that what I specified as the "next protocol type" is coherent with the protocol > >> stack before setting up the filters. Basically, for a valid filter, I should always have > >> rte_flow_item[1].type == rte_flow_item[0].spec.type, and rte_flow_item[2].type == rte_flow_item[1].spec.{type,next_protocol} > >> (except for L2.5 protocol as I experienced, which makes thinks confusing). Couldn't the API leverage this fact so that I don't > >> need to specify the ether_type, TPID, next_protocol_id, ... which are redundant with rte_flow_item.type ? > > >Just to be clear, as a user you don't *need* to provide them, however the > >API certainly does not prevent you to do so. Only masked fields are > >relevant, and the default item masks (rte_flow_item_*_mask) do not include > >protocol types because as you're pointing out, that would indeed be a pain. > > >Is the documentation not clear enough regarding this? > >(see "8.2.3 Pattern item") > > To me it wasn't clear that the PMD/DPDK would take care of "type" fields in network headers for me, > hence, I tried to set them correctly (and got it wrong for ether_type/tpid) -- I feared that filtering on VLAN tci > without restricting to VLAN packets (setting ether_type) would be undefined behavior. I just check ixgbe_flow and > as you said it just ignores the types and relies on the stack so my previous comment and suggestion > was wrong. Phew, I'm relieved! > The documentation is very clear on struct and how to use them, but a few common examples (in C) would have been useful to me; > for example I could have noticed that the example never set the ether_type & cie. testpmd is hard to read as an example. I understand, testpmd is really meant to validate PMD functionality, it's probably not the best implementation example to start with. I'll keep that in mind during future evolutions. > > I think adding custom types would be more complicated than the current > > approach of leaving the payload type field unspecified or set it to some > > custom value that PMDs may or may not accept depending on their > > capabilities. > > You're right. My comment was based on the misconception that it was mandatory to correctly specify ether_types / next_protocol_id / ... Well thanks to that you've raised an interesting issue with the VLAN item (TBH Wenzhuo and other people warned me about that, at the time I was certain it would not be a problem.) I'll attempt to address it as soon as possible. Best regards, -- Adrien Mazarguil 6WIND