DPDK patches and discussions
 help / color / mirror / Atom feed
From: Shahaf Shuler <shahafs@mellanox.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC PATCH 0/4] ethdev new offloads API
Date: Sun, 27 Aug 2017 06:05:25 +0000	[thread overview]
Message-ID: <VI1PR05MB3149BE7E0AEC98C340542D8BC3990@VI1PR05MB3149.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <20170825103136.GD9774@jerin>

Friday, August 25, 2017 1:32 PM, Jerin Jacob:
> >
> > The new API does not have an equivalent for the below Tx flags:
> >
> > * ETH_TXQ_FLAGS_NOREFCOUNT
> > * ETH_TXQ_FLAGS_NOMULTMEMP
> 
> IMO, it make sense to keep those flags as PMD optimization if an application
> does not need reference count and multi mempool in the application.
> As example, An non trivial application like l3fwd does not need both of them.

The l3fwd application is yet another simple example from DPDK tree. Am not sure that a complete vRouter/vSwitch implementation is with the same characteristics.
Moreover, I think the fact there is an application which is able to use it is not enough.  IMO there needs to be some basic functionality always provided by the PMDs and not controlled by flags.
For example, let's say we have an application which always sends the mbufs with the same ol_flags, or even with the same length.
Will it make sense to add more flags to control it?
Will it makes sense to run RFC2544 benchmark with testpmd io forwarding with those flags? 

If the answer is yes, maybe those flags (and others to follow) belong on different location on ethdev. However for sure they are not offloads.

  reply	other threads:[~2017-08-27  6:05 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-07 10:54 Shahaf Shuler
2017-08-07 10:54 ` [dpdk-dev] [RFC PATCH 1/4] ethdev: rename Rx and Tx configuration structs Shahaf Shuler
2017-08-23 21:39   ` Thomas Monjalon
2017-08-07 10:54 ` [dpdk-dev] [RFC PATCH 2/4] ethdev: introduce Rx queue offloads API Shahaf Shuler
2017-08-23 12:21   ` Ananyev, Konstantin
2017-08-23 13:06     ` Shahaf Shuler
2017-08-23 21:48   ` Thomas Monjalon
2017-08-29 12:50   ` Ferruh Yigit
2017-08-30  6:22     ` Shahaf Shuler
2017-08-29 13:11   ` Ferruh Yigit
2017-08-07 10:54 ` [dpdk-dev] [RFC PATCH 3/4] ethdev: introduce Tx " Shahaf Shuler
2017-08-07 10:54 ` [dpdk-dev] [RFC PATCH 4/4] ethdev: add helpers to move to the new " Shahaf Shuler
2017-08-23 12:28   ` Ananyev, Konstantin
2017-08-23 13:13     ` Shahaf Shuler
2017-08-23 22:06       ` Thomas Monjalon
2017-08-24  7:12         ` Shahaf Shuler
2017-08-25 13:26           ` Thomas Monjalon
2017-08-29 12:55             ` Ferruh Yigit
2017-08-30  6:30               ` Shahaf Shuler
2017-08-30  7:50                 ` Ferruh Yigit
2017-08-30 10:16                   ` Ananyev, Konstantin
2017-08-30 12:42                     ` Ferruh Yigit
2017-08-30 13:25                       ` Thomas Monjalon
2017-08-30 14:15                       ` Ananyev, Konstantin
2017-08-28 14:12       ` Ananyev, Konstantin
2017-08-29  6:26         ` Shahaf Shuler
2017-08-29  9:43           ` Ananyev, Konstantin
2017-08-23  6:39 ` [dpdk-dev] [RFC PATCH 0/4] ethdev " Shahaf Shuler
2017-08-23 22:16 ` Thomas Monjalon
2017-08-25 10:31 ` Jerin Jacob
2017-08-27  6:05   ` Shahaf Shuler [this message]
2017-08-28  5:00     ` Jerin Jacob
2017-08-28 10:57       ` Thomas Monjalon
2017-09-05  7:07         ` Jerin Jacob

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=VI1PR05MB3149BE7E0AEC98C340542D8BC3990@VI1PR05MB3149.eurprd05.prod.outlook.com \
    --to=shahafs@mellanox.com \
    --cc=dev@dpdk.org \
    --cc=jerin.jacob@caviumnetworks.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).