DPDK patches and discussions
 help / color / mirror / Atom feed
From: David Marchand <david.marchand@6wind.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] DPDK 2.2 roadmap
Date: Tue, 15 Sep 2015 11:16:17 +0200	[thread overview]
Message-ID: <CALwxeUvb=QNkJE4aivsOw9wzDA=GEpiGyaRCKRLDkhs3mzzsAA@mail.gmail.com> (raw)
In-Reply-To: <1882381.9qlZTmz9zB@xps13>

Hello all,

My turn.

As far as the 2.2 is concerned, I have some fixes/changes waiting for going
upstream :
- allow default mac removal (to be discussed)
- kvargs api updates / cleanup (no change on abi, I would say)
- vlan filtering api fixes and ixgbevf/igbvf associated fixes (might have
an impact on abi)
- ethdev fixes wrt hotplug framework
- minor fixes in testpmd

After this, depending on the schedule (so will most likely be for 2.3 or
later), I have some ideas on :
- cleanup for hotplug and maybe discussions on pci bind/unbind operations
- provide a little tool to have informations/capabilities on drivers (à la
modinfo)
- continue work on hotplug


By the way, I have some questions to the community :

- I noticed that with hotplug support, testpmd has become *really* hungry
on mbufs and memory.
The problem comes from the "basic" assumption that we must have enough
memory/mbufs for the maximum number of ports that might be available but
are not in the most common tests setup.
One solution might be to rework the way mbufs are reserved :
* either we let testpmd start with limited mbufs count the way it was
working before edab33b1 ("app/testpmd: support port hotplug"), then when
trying to start a port, this operation can fail if not enough mbufs are
available for it
* or we can try to create one mempool per port. The mempools would be
populated at the port init / close (?).
Anyone volunteers to rework this ?
Other ideas ?


- looking at a patch from Chao (
http://dpdk.org/ml/archives/dev/2015-August/022819.html), I think we need
to rework the way the numa nodes are handled in the dpdk.
The problem is that we rely on static arrays for some resources per socket.
I suppose this was designed with the idea that socket "physical" indexes
are contiguous, but this is not true on systems running power8 bare metal
(where numa indexes can be 0, 1, 16, 17 on quad nodes servers).
I suppose we can go with a mapping array (populated at the same time cpus
are discovered), then use this mapping array and preserve all apis, but
this might not be that trivial.
Volunteers ?
Ideas ?


- finally, looking at the eal, there are still some cleanups to do.
More specifically, are there any users of the ivshmem feature in dpdk ?
I can see little value in keeping the ivshmem feature in the eal (well
maybe because I don't use it) as it relies on hacks.
So I can see two options:
* someone still wants it to work, then we need a good rework to get rid of
those hacks under #ifdef in eal and the special configuration files can
disappear
* or if nobody complains, we can schedule its deprecation then removal.


Thanks.

-- 
David Marchand

  parent reply	other threads:[~2015-09-15  9:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-09  8:44 Thomas Monjalon
2015-09-09 12:56 ` O'Driscoll, Tim
2015-09-10 12:43   ` Thomas Monjalon
2015-09-10 13:26     ` Thomas F Herbert
2015-09-10 19:27     ` Flavio Leitner
2015-09-10 19:55       ` Thomas Monjalon
2015-09-11  1:23         ` Yuanhan Liu
2015-09-11  8:08     ` O'Driscoll, Tim
2015-09-14  8:40     ` Zhang, Helin
2015-09-14  8:57       ` Thomas Monjalon
2015-09-15 20:11         ` Olga Shern
2015-09-09 17:48 ` Patel, Rashmin N
2015-09-09 18:00   ` Stephen Hemminger
2015-09-15  9:16 ` David Marchand [this message]
2015-09-14 13:44 Matej Vido
2015-09-14 14:02 ` Thomas Monjalon
2015-09-14 15:37   ` Matej Vido

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='CALwxeUvb=QNkJE4aivsOw9wzDA=GEpiGyaRCKRLDkhs3mzzsAA@mail.gmail.com' \
    --to=david.marchand@6wind.com \
    --cc=dev@dpdk.org \
    --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).