DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: "Nicolau, Radu" <radu.nicolau@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "Lu, Wenzhuo" <wenzhuo.lu@intel.com>,
	"Doherty, Declan" <declan.doherty@intel.com>
Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: add security statistics
Date: Tue, 10 Sep 2019 13:02:48 +0000	[thread overview]
Message-ID: <2601191342CEEE43887BDE71AB9772580191962399@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <f42a9154-c7af-2754-14c2-1a9985830962@intel.com>

Hi Radu,

> >
> >> Update IXGBE PMD with support for IPsec statistics.
> > The proposed approach - have a new hash table per device,
> > plus parse  each packet on RX and TX and do hash lookup
> > seems way too heavy to put it into PMD.
> 
> It is indeed heavy, but it's disabled by default and it only uses the
> heavy section when the app is enabling per-session statistics

As I can read  the code, disruption will be much more significant - 
even if user will enable statistics just for one SA (which might never be used),
that will affect whole device: all RX (or all TX) queues will experience a slowdown.
Even RX/TX for queues without any IPsec packets will be affected
(though not that severe as ones with mix of IPsec and non-IPsec or pure IPsec packets).   

> 
> > Wonder why we need to do that?
> > If HW doesn't provide such statistic info, why not to leave it
> > to the upper layer to collect/maintain?
> > In many cases SW will already have that infrastructure
> > and I don't see to put all these heavy-weight operations
> > into ixgbe rx/tx path.
> 
> The reason is to use the rte_security API consistently and take
> advantage of the hardware backed statistics when they are available.

AFAIK, right now in rte_security API there is no option to request statistics per session,
and struct rte_security_ipsec_stats is literally empty.
That's an extension you proposed by the patch:
http://patches.dpdk.org/patch/58462/
But as I can see it is not backed up by any real HW implementation.
Yours current patch provides pure SW implementation,
and I don't see absolutely no reason to push it into the ixgbe PMD.
Same statistics could be collected by dozen different and probably more effective ways without affecting the actual ixgbe driver
(RX/TX callback or  new option in librte_ipsec or new function that would be called by app directly or ...).
So my suggestion let's postpone introducing new API here till we'll have real HW that supports it.

Konstantin


      reply	other threads:[~2019-09-10 13:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-06 16:41 Radu Nicolau
2019-09-08 11:45 ` Ananyev, Konstantin
2019-09-09 11:00   ` Nicolau, Radu
2019-09-10 13:02     ` Ananyev, Konstantin [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=2601191342CEEE43887BDE71AB9772580191962399@irsmsx105.ger.corp.intel.com \
    --to=konstantin.ananyev@intel.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=radu.nicolau@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).