From: David Marchand <david.marchand@6wind.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: 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
next prev 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 DPDK 2.2 roadmap 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]
-- strict thread matches above, loose matches on Subject: below --
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.