From: "Zhang, Helin" <helin.zhang@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>,
"O'Driscoll, Tim" <tim.o'driscoll@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] DPDK 2.2 roadmap
Date: Mon, 14 Sep 2015 08:40:20 +0000 [thread overview]
Message-ID: <F35DEAC7BCE34641BA9FAC6BCA4A12E70A8FBC67@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <2207263.dDyMmkz5Pr@xps13>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Thursday, September 10, 2015 8:44 PM
> To: O'Driscoll, Tim
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] DPDK 2.2 roadmap
>
> 2015-09-09 12:56, O'Driscoll, Tim:
> > DCB for i40e &X550: DCB support will be extended to the i40e and X550 NICs.
Yes, i40e DCB will be enabled in R2.2.
>
> A patch for DCB on X550 is already applied but the release notes part was
> forgotten.
>
> > IPsec Sample App: A sample application will be provided to show how
> > the cryptodev library can be used to implement IPsec. This will be
> > based on the NetBSD IPsec implementation.
>
> For each API, it is really interesting to have some unit tests and some examples to
> show how it should be used. However adding an IPsec stack looks to be beyond
> the need of an API example. It may be big and difficult to maintain when
> updating DPDK.
> Why not spawn a new project here: http://dpdk.org/browse/ ?
>
> > Refactor EAL for Non-PCI Devices: This has been discussed extensively on the
> mailing list. See the RFCs for Refactor eal driver registration code
> (http://dpdk.org/ml/archives/dev/2015-September/023257.html) and Remove
> pci driver from vdevs
> (http://dpdk.org/ml/archives/dev/2015-August/023016.html).
>
> I have the feeling we should think it as an unification work to reduce differences
> between physical and virtual devices handling.
> Probably it will have to be continued during 2.3 cycle.
>
> > Vhost Multi-Queue Support: The vhost-user library will be updated to provide
> multi-queue support in the host similar to the RSS model so that guest driver may
> allocate multiple rx/tx queues which then may be used to load balance between
> cores. See http://dpdk.org/ml/archives/dev/2015-August/022758.html for more
> details.
>
> Does it require a patch on Qemu?
>
> > Config Granularity of RSS for i40e: All RSS hash and filter configurations for
> IPv4/v6, TCP/UDP, GRE, etc will be implemented for i40e. This includes support
> for QinQ and tunneled packets.
>
> What is missing in i40e RSS/filtering?
The fields used for HASH-ing is configured by firmware, some of users want to have
a bit more flexibility on selecting packet fields for hashing.
>
> > I40e 32-bit GRE Keys: Both 24 and 32 bit keys for GRE will be supported for
> i40e.
>
> Could you please give more details?
Currently only 24 bits of GRE key will be used for hash/filter calculation, while 32 bits
was wanted by some of users. So either 24 or 32 bits can be selected by the users
from R2.2.
>
> > X550 Enhancements: Support VF TSO, more Entries in RSS and per VF RSS,
> network overlay support with flow director for X550.
>
> Could you please give more details on "network overlay support with flow
> director"?
X550 hardware supports flow director on tunneled packets (VXLAN/NVGRE), these
will be enabled from R2.2.
Regards,
Helin
>
> Thanks for sharing your plan
next prev parent reply other threads:[~2015-09-14 8:41 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 [this message]
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
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=F35DEAC7BCE34641BA9FAC6BCA4A12E70A8FBC67@SHSMSX104.ccr.corp.intel.com \
--to=helin.zhang@intel.com \
--cc=dev@dpdk.org \
--cc=thomas.monjalon@6wind.com \
--cc=tim.o'driscoll@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).