From: Bruce Richardson <bruce.richardson@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: ferruh.yigit@intel.com, dev@dpdk.org,
Yuanhan Liu <yuanhan.liu@linux.intel.com>,
Maxime Coquelin <maxime.coquelin@redhat.com>,
Jing Chen <jing.d.chen@intel.com>,
Helin Zhang <helin.zhang@intel.com>,
Jingjing Wu <jingjing.wu@intel.com>,
Wenzhuo Lu <wenzhuo.lu@intel.com>,
Konstantin Ananyev <konstantin.ananyev@intel.com>
Subject: Re: [dpdk-dev] SIMD Rx/Tx paths
Date: Mon, 15 May 2017 14:15:17 +0100 [thread overview]
Message-ID: <20170515131517.GA68644@bricha3-MOBL3.ger.corp.intel.com> (raw)
In-Reply-To: <1857248.OtrprS2xZT@xps>
On Mon, May 15, 2017 at 02:35:55PM +0200, Thomas Monjalon wrote:
> Hi,
>
> I would like to open a discussion about SIMD code in drivers.
>
> I think we should not have different behaviours or features capabilities,
> in the different code paths of a same driver.
> I suggest to consider such differences as exceptions.
> So we should merge features files (i.e. matrix columns),
> and remove these files:
>
> % ls doc/guides/nics/features/*_vec.ini
>
> doc/guides/nics/features/fm10k_vec.ini
> doc/guides/nics/features/fm10k_vf_vec.ini
> doc/guides/nics/features/i40e_vec.ini
> doc/guides/nics/features/i40e_vf_vec.ini
> doc/guides/nics/features/ixgbe_vec.ini
> doc/guides/nics/features/ixgbe_vf_vec.ini
> doc/guides/nics/features/virtio_vec.ini
>
> If a feature is not supported in all code paths of a driver,
> it must be marked as partially (P) supported.
>
> Then the mid-term goal will be to try removing these inconsistencies.
>
> Opinions/comments?
Yes, there are inconsistencies, but if they are hidden from the user,
e.g. by having the driver select automatically the most appropriate
path, I don't think we should need to mark the support as "partial".
Instead, it should be marked as being fully supported, but perhaps with
a note indicating that a performance hit may be experienced due to the
code taking a less-optimised driver path. After all, especially in the
TX code path, a lot of the speed-up comes from not supporting different
features, as well as from the vectorization. In those cases "closing the
gap" may mean losing performance for those who don't want the features,
which is not acceptable. Any feature support we can add, without
affecting performance, should of course be implemented.
/Bruce
next prev parent reply other threads:[~2017-05-15 13:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-15 12:35 Thomas Monjalon
2017-05-15 13:15 ` Bruce Richardson [this message]
2017-05-15 13:36 ` Ferruh Yigit
2017-05-15 14:12 ` Richardson, Bruce
2017-05-15 14:26 ` Thomas Monjalon
2017-05-16 0:54 ` Chen, Jing D
2017-05-16 5:36 ` Shahaf Shuler
2017-05-16 9:27 ` Bruce Richardson
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=20170515131517.GA68644@bricha3-MOBL3.ger.corp.intel.com \
--to=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=helin.zhang@intel.com \
--cc=jing.d.chen@intel.com \
--cc=jingjing.wu@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=maxime.coquelin@redhat.com \
--cc=thomas@monjalon.net \
--cc=wenzhuo.lu@intel.com \
--cc=yuanhan.liu@linux.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).