From: Bruce Richardson <bruce.richardson@intel.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 2/3] pmd: RX function need keep EXTERNAL_MBUF flag
Date: Fri, 24 Oct 2014 13:34:58 +0100 [thread overview]
Message-ID: <20141024123458.GA7648@BRICHA3-MOBL> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB9772582139EBAF@IRSMSX105.ger.corp.intel.com>
On Fri, Oct 24, 2014 at 10:46:06AM +0000, Ananyev, Konstantin wrote:
> Hi Changchun,
>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ouyang Changchun
> > Sent: Friday, October 24, 2014 9:10 AM
> > To: dev@dpdk.org
> > Subject: [dpdk-dev] [PATCH 2/3] pmd: RX function need keep EXTERNAL_MBUF flag
> >
> > Every pmd RX function need keep the EXTERNAL_MBUF flag
> > in mbuf.ol_flags, and can't overwrite it when filling ol_flags from
> > descriptor to mbuf, otherwise, it probably cause to crash when freeing a mbuf
> > and trying to freeing its attached external buffer, say, from guest space.
> >
>
> Don't really like the idea to put:
> mb->ol_flags = pkt_flags | (mb->ol_flags & EXTERNAL_MBUF);
> in each and every PMD from now on...
>
> From other side, it is probably not very good that RX functions update whole ol_flags, not only RX related part.
> Wonder can we reserve low 32bits of ol_flags for RX, and high 32bits for TX and generic stuff.
> So our ol_flags will look something like that:
>
> union {
> uint64_t ol_raw_flags;
> struct {
> uint32_t rx;
> uint32_t gen_tx;
> } ol_flags
> };
>
> And make all PMD RX functions to operate on rx part of the flags only:
> mb->ol_flags.rx = pkt_flags;
> ?
>
> Konstantin
>
I would tend to agree with this. Changchun, did you get to assess the
performance impact of making this change to the PMDs? I suspect that making
the changes to each PMD would impact performance, while Konstantin's
suggestion should eliminate that impact.
The downside there is that we are limiting the flexibility we have in
expanding beyond 32 RX flags and 24 TX flags. :-(
/Bruce
next prev parent reply other threads:[~2014-10-24 12:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-24 8:10 [dpdk-dev] [PATCH 0/3] Vhost app removes dependency of REFCNT Ouyang Changchun
2014-10-24 8:10 ` [dpdk-dev] [PATCH 1/3] mbuf: Use EXTERNAL_MBUF to indicate external buffer Ouyang Changchun
2014-10-24 8:10 ` [dpdk-dev] [PATCH 2/3] pmd: RX function need keep EXTERNAL_MBUF flag Ouyang Changchun
2014-10-24 10:46 ` Ananyev, Konstantin
2014-10-24 12:34 ` Bruce Richardson [this message]
2014-10-24 15:43 ` Bruce Richardson
2014-10-24 15:58 ` Ananyev, Konstantin
2014-10-25 2:08 ` Ouyang, Changchun
2014-10-24 8:10 ` [dpdk-dev] [PATCH 3/3] vhost: Removes dependency on REFCNT for zero copy Ouyang Changchun
2014-10-24 9:47 ` [dpdk-dev] [PATCH 0/3] Vhost app removes dependency of REFCNT Thomas Monjalon
2014-10-24 10:47 ` Bruce Richardson
2014-10-25 1:01 ` Ouyang, Changchun
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=20141024123458.GA7648@BRICHA3-MOBL \
--to=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=konstantin.ananyev@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).