DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jan Blunck <jblunck@infradead.org>
To: Olivier MATZ <olivier.matz@6wind.com>
Cc: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC 0/8] mbuf: structure reorganization
Date: Tue, 21 Feb 2017 17:12:12 +0100	[thread overview]
Message-ID: <CALe+Z03meh2od13-pfnFh0SpmCqxgKLD5MG2MF5Bj9Q8EtS=Hw@mail.gmail.com> (raw)
In-Reply-To: <20170221105400.2eba4747@glumotte.dev.6wind.com>

On Tue, Feb 21, 2017 at 10:54 AM, Olivier MATZ <olivier.matz@6wind.com> wrote:
> Hi Jan,
>
> On Mon, 20 Feb 2017 10:27:40 +0100, Jan Blunck <jblunck@infradead.org>
> wrote:
>> On Fri, Feb 17, 2017 at 3:17 PM, Olivier Matz
>> <olivier.matz@6wind.com> wrote:
>> >
>> > Sorry, I don't really get your point. My comprehension of the
>> > timestamp usage in a PMD is as following:
>> >
>> > rx_burst(struct rxq *rxq, ...)
>> > {
>> >         unsigned long factor = rxq->timestamp_factor;
>> >         unsigned port = rxq->port;
>> >
>> >         for each hw_desc {
>> >                 m = rte_pktmbuf_alloc(rxq->pool);
>> >                 m->len = hw_desc->len;
>> >                 m->port = port;
>> >                 m->ol_flags =
>> >                 ...
>> >                 m->timestamp = hw_desc->timestamp * factor;
>> >         }
>> >         ...
>> > }
>> >
>> > In that case, I think it deserves to be in the 1st cache line.
>> >
>>
>> Timestamps are non-functional data. I believe they don't deserve to be
>> data normalized.
>
> I don't really see why timestamp is non-functional, compared to rss
> hash, flow director id, packet type, seqn, ...
>

One doesn't drop, forward, reorder or decrypt packets based on the
timestamp value.

Common use cases for timestamps are analytics applications or circuit
breakers where you want to ensure that your algos don't act upon stale
data. This is more application layer / slow path work.

> I think the goal of DPDK is to provide a generic/normalized API for
> such features (like for offload), so it can be used by an application
> whatever the underlying driver.
>

I believe there is a difference between dataplane relevant
functionally and non-functional features. If you structurally
normalize the later you will end up making everyone pay for a feature
that is only relevant to a particular group of users. In that case I
would at least expect that the support for timestamps can get selected
at compile time.

>>
>> It would be beneficial to normalize the access of non-functional data.
>> That would require some kind of extension or feature flags, e.g. like
>> some uverb structures support extensions. This would allow the NICs
>> that support timestamps to do the minimal amount of work during burst
>> and defer data normalization to the time of access. That would also
>> safe everyone from wasting 64bit in the first cacheline in case
>> timestamps are not supported or unused.
>
> I agree that we could start to think about "extensible" mbufs. In few
> words, I think we could have:
> - only general fields are static
> - the application registers room in mbuf structure for all features it
>   will use
> It would rationalize the room used in mbuf, at the cost of a more
> complex/slow access to the data in PMDs and application, since the
> offset won't be static.
>

Access through PMD specific function pointers should be relatively
fast on access. Modern architecture optimize that use case well
enough.

> But to me, this is another work, and a much harder one since it will
> impact a lot of PMD code (some are using vector instructions and are
> quite hard to change). Moreover, we first have to prove that it would
> perform better than we we have now, especially knowing that size of the
> cache line will probably change to 128B for many architectures.
>
> Now back on the patch, yes, it's true we are consuming 64bits in the
> first cache line. But what are the other options? Having it in the
> second cache line would allow free this space for future use. But don't
> you think we could optimize current use, and rework the structure if
> new needs -- that are more important than timestamp for the majority--
> appear?

What is you plan for devices that already put the timestamp relative
to the packet data? Do you still want to duplicate and normalize it
into the rte_mbuf field?

What is recommended to do for PMDs that don't support HW timestamps?
Do they still fill this field?

  reply	other threads:[~2017-02-21 16:12 UTC|newest]

Thread overview: 155+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-24 15:19 Olivier Matz
2017-01-24 15:19 ` [dpdk-dev] [RFC 1/8] mbuf: make segment prefree function public Olivier Matz
2017-01-24 15:19 ` [dpdk-dev] [RFC 2/8] mbuf: make raw free " Olivier Matz
2017-01-24 15:19 ` [dpdk-dev] [RFC 3/8] mbuf: set mbuf fields while in pool Olivier Matz
2017-01-24 15:50   ` Bruce Richardson
2017-02-28 14:51     ` Olivier Matz
2017-01-24 15:19 ` [dpdk-dev] [RFC 4/8] net: don't touch mbuf next or nb segs on Rx Olivier Matz
2017-01-24 15:19 ` [dpdk-dev] [RFC 5/8] mbuf: make rearm data address naturally aligned Olivier Matz
2017-01-24 15:19 ` [dpdk-dev] [RFC 6/8] mbuf: use 2 bytes for port and nb segments Olivier Matz
2017-01-24 15:19 ` [dpdk-dev] [RFC 7/8] mbuf: move sequence number in second cache line Olivier Matz
2017-01-24 15:19 ` [dpdk-dev] [RFC 8/8] mbuf: add a timestamp field Olivier Matz
2017-01-24 15:59 ` [dpdk-dev] [RFC 0/8] mbuf: structure reorganization Bruce Richardson
2017-01-24 16:16   ` Olivier MATZ
2017-02-06 18:41 ` Ananyev, Konstantin
2017-02-09 16:20   ` Morten Brørup
2017-02-09 16:56     ` Ananyev, Konstantin
2017-02-16 13:48   ` Olivier Matz
2017-02-16 15:46     ` Bruce Richardson
2017-02-16 16:14       ` Olivier Matz
2017-02-21 14:20         ` Morten Brørup
2017-02-21 14:28           ` Bruce Richardson
2017-02-21 15:04           ` Olivier MATZ
2017-02-21 15:18             ` Bruce Richardson
2017-02-21 15:18             ` Morten Brørup
2017-02-19 19:04       ` Chilikin, Andrey
2017-02-21  9:53         ` Olivier MATZ
2017-02-16 17:26     ` Jan Blunck
2017-02-17 10:51       ` Olivier Matz
2017-02-17 12:49         ` Nélio Laranjeiro
2017-02-17 13:51           ` Jan Blunck
2017-02-18  5:48             ` Andrew Rybchenko
2017-02-17 13:38         ` Jan Blunck
2017-02-17 14:17           ` Olivier Matz
2017-02-17 18:42             ` Ananyev, Konstantin
2017-02-21  9:53               ` Olivier MATZ
2017-02-21 10:28                 ` Ananyev, Konstantin
2017-02-20  9:27             ` Jan Blunck
2017-02-21  9:54               ` Olivier MATZ
2017-02-21 16:12                 ` Jan Blunck [this message]
2017-02-21 16:38                   ` Bruce Richardson
2017-02-21 17:04                     ` Jan Blunck
2017-02-21 17:26                       ` Ananyev, Konstantin
2017-02-21 19:17                         ` Jan Blunck
2017-02-21 20:30                           ` Ananyev, Konstantin
2017-02-21 21:51                             ` Morten Brørup
2017-02-24 14:11                               ` Olivier Matz
2017-02-24 14:00                             ` Olivier Matz
2017-02-24 14:21                               ` Bruce Richardson
2017-02-28  8:55                               ` Jan Blunck
2017-02-28  9:05                                 ` Ananyev, Konstantin
2017-02-28  9:23                                   ` Olivier Matz
2017-02-28  9:33                                     ` Jan Blunck
2017-02-28 10:29                                     ` Ananyev, Konstantin
2017-02-28 10:50                                       ` Olivier Matz
2017-02-28 11:48                                         ` Ananyev, Konstantin
2017-02-28 12:28                                           ` Olivier Matz
2017-02-28 22:53                                             ` Ananyev, Konstantin
2017-03-02 16:46                                               ` Olivier Matz
2017-03-08 11:11                                                 ` Ananyev, Konstantin
2017-03-20  9:00                                                   ` Olivier Matz
2017-03-22 17:42                                                     ` Ananyev, Konstantin
2017-03-24  8:35                                                       ` Jerin Jacob
2017-03-24 13:35                                                         ` Olivier Matz
2017-02-28  9:25                                   ` Jan Blunck
2017-02-19 23:45     ` Ananyev, Konstantin
2017-02-21  9:22     ` Morten Brørup
2017-02-21  9:54       ` Olivier MATZ
2017-03-08  9:41 ` [dpdk-dev] [PATCH 0/9] " Olivier Matz
2017-03-08  9:41   ` [dpdk-dev] [PATCH 1/9] mbuf: make segment prefree function public Olivier Matz
2017-03-08  9:41   ` [dpdk-dev] [PATCH 2/9] mbuf: make raw free " Olivier Matz
2017-03-08  9:41   ` [dpdk-dev] [PATCH 3/9] mbuf: set mbuf fields while in pool Olivier Matz
2017-03-31 11:21     ` Bruce Richardson
2017-03-31 11:51       ` Ananyev, Konstantin
2017-03-08  9:41   ` [dpdk-dev] [PATCH 4/9] drivers/net: don't touch mbuf next or nb segs on Rx Olivier Matz
2017-03-08  9:41   ` [dpdk-dev] [PATCH 5/9] mbuf: make rearm data address naturally aligned Olivier Matz
2017-03-08  9:41   ` [dpdk-dev] [PATCH 6/9] mbuf: use 2 bytes for port and nb segments Olivier Matz
2017-03-08  9:41   ` [dpdk-dev] [PATCH 7/9] mbuf: move sequence number in second cache line Olivier Matz
2017-03-08  9:42   ` [dpdk-dev] [PATCH 8/9] mbuf: add a timestamp field Olivier Matz
2017-04-04 10:29     ` [dpdk-dev] [PATCH 0/2] reduce writes to mbuf in ixgbe vRX Konstantin Ananyev
2017-04-07 15:13       ` Ferruh Yigit
2017-04-07 15:44         ` Ferruh Yigit
2017-04-09 22:56           ` Ananyev, Konstantin
2017-04-04 10:29     ` [dpdk-dev] [PATCH 1/2] net/ixgbe: eliminate mbuf write on rearm Konstantin Ananyev
2017-04-10 15:59       ` [dpdk-dev] [PATCH v2 0/2] reduce writes to mbuf in ixgbe vRX Konstantin Ananyev
2017-04-10 16:17         ` Ferruh Yigit
2017-04-10 15:59       ` [dpdk-dev] [PATCH v2 1/2] net/ixgbe: eliminate mbuf write on rearm Konstantin Ananyev
2017-04-10 15:59       ` [dpdk-dev] [PATCH v2 2/2] net/ixgbe: remove option to disable offload flags Konstantin Ananyev
2017-04-04 10:29     ` [dpdk-dev] [PATCH " Konstantin Ananyev
2017-03-08  9:42   ` [dpdk-dev] [PATCH 9/9] mbuf: reorder VLAN tci and buffer len fields Olivier Matz
2017-03-29 15:56   ` [dpdk-dev] [PATCH 0/9] mbuf: structure reorganization Olivier Matz
2017-03-29 16:03     ` Morten Brørup
2017-03-29 20:09     ` Bruce Richardson
2017-03-30  9:31       ` Bruce Richardson
2017-03-30 12:02         ` Olivier Matz
2017-03-30 12:23           ` Bruce Richardson
2017-03-30 16:45             ` Ananyev, Konstantin
2017-03-30 16:47               ` Ananyev, Konstantin
2017-03-30 18:06                 ` Ananyev, Konstantin
2017-03-31  8:41                   ` Olivier Matz
2017-03-31  9:58                     ` Ananyev, Konstantin
2017-03-31  1:00                 ` Ananyev, Konstantin
2017-03-31  7:21                   ` Morten Brørup
2017-03-31  8:26                   ` Olivier Matz
2017-03-31  8:41                     ` Bruce Richardson
2017-03-31  8:59                       ` Olivier Matz
2017-03-31  9:18                         ` Ananyev, Konstantin
2017-03-31  9:36                           ` Olivier Matz
2017-04-03 16:15                           ` Thomas Monjalon
2017-04-04  7:58                             ` Olivier MATZ
2017-04-04  8:53                               ` Bruce Richardson
2017-03-31  9:23                         ` Bruce Richardson
2017-03-31 11:18     ` Nélio Laranjeiro
2017-03-30 14:54   ` Andrew Rybchenko
2017-03-30 15:12   ` Jerin Jacob
2017-04-04 16:27   ` [dpdk-dev] [PATCH v2 0/8] " Olivier Matz
2017-04-04 16:28     ` [dpdk-dev] [PATCH v2 1/8] mbuf: make segment prefree function public Olivier Matz
2017-04-04 16:28     ` [dpdk-dev] [PATCH v2 2/8] mbuf: make raw free " Olivier Matz
2017-04-04 16:28     ` [dpdk-dev] [PATCH v2 3/8] mbuf: set mbuf fields while in pool Olivier Matz
2017-04-04 16:28     ` [dpdk-dev] [PATCH v2 4/8] drivers/net: don't touch mbuf next or nb segs on Rx Olivier Matz
2017-04-04 16:28     ` [dpdk-dev] [PATCH v2 5/8] mbuf: make rearm data address naturally aligned Olivier Matz
2017-04-04 16:28     ` [dpdk-dev] [PATCH v2 6/8] mbuf: use 2 bytes for port and nb segments Olivier Matz
2017-04-06  5:45       ` Yuanhan Liu
2017-04-18 13:03         ` Olivier MATZ
2017-07-04  7:54           ` Wang, Zhihong
2017-07-10  8:00             ` Olivier Matz
2017-07-10  8:15               ` Morten Brørup
2017-07-11 13:25                 ` Wiles, Keith
2017-07-11 13:30                   ` Morten Brørup
2017-07-11 15:05                     ` Thomas Monjalon
2017-07-11 15:23                       ` [dpdk-dev] [PATCH v2 6/8] mbuf: use 2 bytes for port and nbsegments Morten Brørup
2017-07-11 16:48                         ` Wiles, Keith
2017-07-12  7:25                           ` Morten Brørup
2017-07-12  9:02                             ` Yang, Zhiyong
2017-07-12  9:50                               ` [dpdk-dev] [PATCH v2 6/8] mbuf: use 2 bytes for port andnbsegments Morten Brørup
2017-07-12 15:35                                 ` Stephen Hemminger
2017-07-12 15:57                                   ` Morten Brørup
2017-07-12 16:23                                     ` Thomas Monjalon
2017-07-12 18:20                                       ` Wiles, Keith
2017-07-21 15:03                                       ` Bruce Richardson
2017-07-12 15:34                             ` [dpdk-dev] [PATCH v2 6/8] mbuf: use 2 bytes for port and nbsegments Wiles, Keith
2017-07-11 13:34                 ` [dpdk-dev] [PATCH v2 6/8] mbuf: use 2 bytes for port and nb segments Wiles, Keith
2017-07-11 13:46                   ` Olivier MATZ
2017-04-04 16:28     ` [dpdk-dev] [PATCH v2 7/8] mbuf: move sequence number in second cache line Olivier Matz
2017-04-04 16:28     ` [dpdk-dev] [PATCH v2 8/8] mbuf: add a timestamp field Olivier Matz
2017-04-05  9:37     ` [dpdk-dev] [PATCH v2 0/8] mbuf: structure reorganization Thomas Monjalon
2017-04-05  9:46       ` Olivier MATZ
2017-04-05  9:48       ` Richardson, Bruce
2017-04-05 12:06       ` Ferruh Yigit
2017-04-14 13:10       ` Ferruh Yigit
2017-04-18 13:04         ` Olivier MATZ
2017-04-19  9:39           ` Thomas Monjalon
2017-04-19 12:28             ` Olivier MATZ
2017-04-19 12:56               ` Thomas Monjalon
2017-04-19 13:03                 ` Ferruh Yigit
2017-04-19 13:12                   ` Thomas Monjalon

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='CALe+Z03meh2od13-pfnFh0SpmCqxgKLD5MG2MF5Bj9Q8EtS=Hw@mail.gmail.com' \
    --to=jblunck@infradead.org \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@intel.com \
    --cc=olivier.matz@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).