All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrien Mazarguil <adrien.mazarguil@6wind.com>
To: Qi Zhang <qi.z.zhang@intel.com>
Cc: dev@dpdk.org, wenzhuo.lu@intel.com, beilei.xing@intel.com
Subject: Re: [RFC 0/2] ethdev: add new attribute for signature match
Date: Wed, 17 May 2017 12:32:41 +0200	[thread overview]
Message-ID: <20170517103241.GD1758@6wind.com> (raw)
In-Reply-To: <1494791406-3594-1-git-send-email-qi.z.zhang@intel.com>

On Sun, May 14, 2017 at 03:50:04PM -0400, Qi Zhang wrote:
> We try to enable ixgbe's signature match with rte_flow, but didn't
> find a way with current APIs, so the RFC propose to add a new flow
> attribute "sig_match" to indicate if current flow is "perfect match"
> or "signature match"
> With perfect match (by default), if a packet does not match pattern,
> actions will not be taken. (this is identical with current behavior)
> With signature match, if a packet does not match pattern, it still
> has the possibility to trigger the actions, this happens when device
> think the signature of the pattern is matched.
> Signature match is expected to have better performance than perfect
> match with the cost of accuracy.
> When a flow rule with this attribute set, identical behavior can ONLY
> be guaranteed if packet matches the pattern, since different device
> may have different implementation of signature calculation algorithm.
> Driver of device that does not support signature match is not required to
> return error, but just simply igore this attribute, because the default
>  "perfect match" still can be regarded as a speical case of 
> "signature match".
> 
> Qi Zhang (2):
>   rte_flow: add attribute for signature match
>   doc/guides/prog_guide: add new rte_flow attribute
> 
>  app/test-pmd/cmdline_flow.c        | 11 +++++++++++
>  doc/guides/prog_guide/rte_flow.rst | 12 ++++++++++++
>  lib/librte_ether/rte_flow.h        |  3 ++-
>  3 files changed, 25 insertions(+), 1 deletion(-)

As discussed offline, modifying struct rte_flow_attr for this purpose is not
ideal. We've agreed that a new meta pattern item should be defined instead,
as described in the FDIR rules conversion section (8.9.7) of the
documentation [1].

[1] http://dpdk.org/doc/guides/prog_guide/rte_flow.html#fdir-to-most-item-types-queue-drop-passthru

-- 
Adrien Mazarguil
6WIND

      parent reply	other threads:[~2017-05-17 10:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-14 19:50 [RFC 0/2] ethdev: add new attribute for signature match Qi Zhang
2017-05-14 19:50 ` [RFC 1/2] rte_flow: add " Qi Zhang
2017-05-14 19:50 ` [RFC 2/2] doc/guides/prog_guide: add new flow attribute Qi Zhang
2017-05-16  9:11   ` Mcnamara, John
2017-05-17 10:32 ` Adrien Mazarguil [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170517103241.GD1758@6wind.com \
    --to=adrien.mazarguil@6wind.com \
    --cc=beilei.xing@intel.com \
    --cc=dev@dpdk.org \
    --cc=qi.z.zhang@intel.com \
    --cc=wenzhuo.lu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.