From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Cc: Thomas Monjalon <thomas.monjalon@6wind.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2] doc: announce ABI change for rte_eth_dev structure
Date: Thu, 28 Jul 2016 19:29:16 +0530 [thread overview]
Message-ID: <20160728135915.GA17655@localhost.localdomain> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB97725836B8AB57@irsmsx105.ger.corp.intel.com>
On Thu, Jul 28, 2016 at 01:01:16PM +0000, Ananyev, Konstantin wrote:
>
>
> > > >
> > > > Not according to proposal. It can't be too as application has no
> > > > idea what PMD driver does with "prep" what is the implication on a
> > > > HW if application does not
> > >
> > > Why application writer wouldn't have an idea?
> > > We would document what tx_prep() supposed to do, and in what cases user don't need it.
> >
> > But how he/she detect that on that run-time ?
>
> By the application logic for example.
> If let say is doing the l2fwd for that group of packets, it would know
> that it doesn't need to do tx_prep().
>
> To be honest, I don't understand what is your concern here.
> That proposed change doesn't break any existing functionality,
> doesn't introduce any new requirements to the existing API,
> and wouldn't introduce any performance regression for existing apps.
Yes for the existing application but no for ANY application that uses tx_prep() in future,
that run on the PMD where callback is NULL(one/two PMDs vs N PMDs)
> It is a an extension, and user is free not to use it, if it doesn't fit his needs.
If it is a workaround for a specific HW then why to change the normative
"fastpath" ethdev specification. You could give your fixup as internal
PMD driver routine and be done with it. It is as simple as that.
> From other side there are users who are interested in that functionality,
> and they do have use-cases for it.
> So what worries you?
Above things worries me, I wouldn't have cared if the changes are not comes
in fastpath and I don't think this sort of issues will never get fixed any time
soon in this community.
So I given up.
Jerin
> Konstantin
>
> >
> > > Then it would be up to the user:
> > > - not to use it at all (one segment per packet, no HW TX offloads)
> >
> > We already have TX flags for that
> >
> > > - not to use tx_prep(), and make necessary preparations himself,
> > > that what people have to do now.
> > > - use tx_prep()
> > >
> > > Konstantin
> > >
next prev parent reply other threads:[~2016-07-28 13:59 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-20 14:24 [dpdk-dev] [PATCH] " Tomasz Kulasek
2016-07-20 15:01 ` Thomas Monjalon
2016-07-20 15:13 ` Ananyev, Konstantin
2016-07-20 15:22 ` Thomas Monjalon
2016-07-20 15:42 ` Kulasek, TomaszX
2016-07-21 15:24 ` [dpdk-dev] [PATCH v2] " Tomasz Kulasek
2016-07-21 22:48 ` Ananyev, Konstantin
2016-07-27 8:59 ` Thomas Monjalon
2016-07-27 17:10 ` Jerin Jacob
2016-07-27 17:33 ` Ananyev, Konstantin
2016-07-27 17:41 ` Jerin Jacob
2016-07-27 20:51 ` Ananyev, Konstantin
2016-07-28 2:13 ` Jerin Jacob
2016-07-28 10:36 ` Ananyev, Konstantin
2016-07-28 11:38 ` Jerin Jacob
2016-07-28 12:07 ` Avi Kivity
2016-07-28 13:01 ` Ananyev, Konstantin
2016-07-28 13:58 ` Olivier MATZ
2016-07-28 14:21 ` Ananyev, Konstantin
2016-07-28 13:59 ` Jerin Jacob [this message]
2016-07-28 14:52 ` Thomas Monjalon
2016-07-28 16:25 ` Jerin Jacob
2016-07-28 17:07 ` Thomas Monjalon
2016-07-31 7:50 ` Vlad Zolotarov
2016-07-28 12:04 ` Avi Kivity
2016-07-31 7:46 ` [dpdk-dev] [PATCH] " Vlad Zolotarov
2016-07-31 8:10 ` Vlad Zolotarov
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=20160728135915.GA17655@localhost.localdomain \
--to=jerin.jacob@caviumnetworks.com \
--cc=dev@dpdk.org \
--cc=konstantin.ananyev@intel.com \
--cc=thomas.monjalon@6wind.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).