> config/common_linuxapp |7 +
> lib/Makefile |1 +
> lib/librte_vhost/Makefile| 48 ++
> lib/librte_vhost/eventfd_link/Makefile | 39 +
> lib/librte_vhost/eventfd_link/eventfd_link.c | 194 +
> lib/li
2014-08-12 23:47, Tomas Vestelind:
> I added a function which extracts all the configured keys in a hash map.
> This is good to have when debugging and printing data store in hash
> maps.
Someone to review this patch, please?
(and the other one for rte_hash_clear)
--
Thomas
On Thu, Aug 28, 2014 at 08:00:59PM -0400, daniel chapiesky wrote:
> But, in the end, sharing the meta-data area with the packet headroom seems
> to be a very
> bad idea.
>
> Sincerely,
>
> Daniel Chapiesky
You might have picked a good time to inquire about it as some of the Intel
guys are makin
rte_muf: Inconsistency in the programmer's guide or the code.?
-
>From the DPDK 1.7.0 programmer's guide we read:
"For a newly allocated mbuf, the area at which the data begins in the
message buffer
is RTE_PKTMBUF_HEADROOM bytes
Hello.
I found that DPDK has an abstraction for having multiple devices with
single PCI.
(RTE_PCI_DRV_MULTIPLE flag)
However, their is a naming collision while registering multiple devices.
Here is my possible solution.
Best regards.
Keunhong.
> > No need for that 'x bit' on source files.
> >
> > Signed-off-by: David Marchand
>
> Acked-by: Bruce Richardson
Applied for version 1.7.1.
Thanks
--
Thomas
> When writing to the mbuf array for receiving packets, do not assume
> 16-byte alignment by using aligned stores. If the pointers are only
> 8-byte aligned, the program will crash due to incorrect alignment.
> Changing "store" to "storeu" fixes this.
>
> Signed-off-by: Bruce Richardson
Acked-by
2014-08-28 14:37, Wu, Jingjing:
> Can I send a separate patch for this?
> Because it has no strict relationship with flow director.
Yes, please.
But I think you should look at the removal option (no redefinition
of at all).
Thanks
--
Thomas
The vlan_macip structure combined a vlan tag id with l2 and l3 headers
lengths for tracking offloads. However, this structure was only used as
a unit by the e1000 and ixgbe drivers, not generally.
This patch removes the structure from the mbuf header and places the
fields into the mbuf structure d
In some cases we may want to tag a packet for a particular destination
or output port, so rename the "in_port" field in the mbuf to just "port"
so that it can be re-used for this purpose if an application needs it.
Changes in V2:
* Further updates to apply to latest HEAD on master
Signed-off-by:
From: Olivier Matz
The rte_pktmbuf structure was initially included in the rte_mbuf
structure. This was needed when there was 2 types of mbuf (ctrl and
packet). As the control mbuf has been removed, we can merge the
rte_pktmbuf into the rte_mbuf structure.
Advantages of doing this:
- the acces
From: Olivier Matz
The initial role of rte_ctrlmbuf is to carry generic messages (data
pointer + data length) but it's not used by the DPDK or it applications.
Keeping it implies:
- loosing 1 byte in the rte_mbuf structure
- having some dead code rte_mbuf.[ch]
This patch removes this feature
From: Olivier Matz
It seems that RTE_MBUF_SCATTER_GATHER is not the proper name for the
feature it provides. "Scatter gather" means that data is stored using
several buffers. RTE_MBUF_REFCNT seems to be a better name for that
feature as it provides a reference counter for mbufs.
The macro RTE_MB
Since all unspecified fields in an initializer are assumed to be zero we
can simplify the empty mbuf definition in the vector driver to only use
the fields that are non-zero, i.e. just nb_segs = 1. This makes things
shorter and means that the structure doesn't need as many updates for
other fields
This patch set does some initial pre-work to prepare the mbuf data structure
(and ixgbe vector driver to a lesser extent) for more major changes which
will follow on in a subsequent patch set. [See previous RFC patch set for
more indications of the future coming changes].
The main changes here are
Make ACL library to build/work on 'default' architecture:
- make rte_acl_classify_scalar really scalar
(make sure it wouldn't use sse4 instrincts through resolve_priority()).
- Provide two versions of rte_acl_classify code path:
rte_acl_classify_sse() - could be build and used only on systems wi
2014-08-28 13:39, Wu, Jingjing:
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > I'm OK to change APIs but you should remove the old one, or at least,
> > implement your new API in existing drivers to allow deprecation of the
> > old API.
> > I think it would help if you start by d
On Tue, 12 Aug 2014 23:47:33 +0200
Tomas Vestelind wrote:
> I added a function which extracts all the configured keys in a hash map.
> This is good to have when debugging and printing data store in hash
> maps.
>
> Signed-off-by: Tomas Vestelind
> ---
> lib/librte_hash/rte_hash.c | 26 ++
2014-08-28 14:42, David Marchand:
> - Thomas, RTE_PCI_DRV_MULTIPLE deprecation for 1.8.x ?
Yes, but I don't know how to deprecate a flag.
It could be a simple removal.
--
Thomas
Hello,
On Thu, Aug 28, 2014 at 12:54 PM, ??? wrote:
> I found that DPDK has an abstraction for having multiple devices with
> single PCI.
> (RTE_PCI_DRV_MULTIPLE flag)
> However, their is a naming collision while registering multiple devices.
> Here is my possible solution.
>
- Actually, I thin
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Thursday, August 28, 2014 4:56 PM
> To: Wu, Jingjing
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 5/7] fix the Marco conflict
>
> 2014-08-28 03:39, Wu, Jingjing:
> > Because these macr
2014-08-28 11:02, Liu, Jijiang:
> From: Thomas Monjalon
> > 2014-08-28 00:55, Liu, Jijiang:
> > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > > I wonder if we could use a common function to set all kind of filters?
> > > >
> > > > Thoughts are welcome.
> > >
> > > The rte_eth_
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Thursday, August 28, 2014 10:21 PM
> To: Wu, Jingjing
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API
> rx_classification_filter_ctl
>
> 2014-08-28 13:3
Hi, Konstantin
Thanks a lot.
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Thursday, August 28, 2014 7:49 PM
> To: Thomas Monjalon; Wu, Jingjing
> Cc: dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API
> rx_classification_filter_ctl
>
>
>
2014-08-28 11:30, Ananyev, Konstantin:
> From: Thomas Monjalon
> > 2014-08-28 09:01, Wu, Jingjing:
> > > I have another question:
> > > If we use the way 'rx_classification_filter_ctl' works, the specific
> > > structures defined in rte_i40e.h will be visible in user's application,
> > > such as te
Hi, Thomas
Please see my comments below.
Thanks a lot.
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Thursday, August 28, 2014 6:56 PM
> To: Wu, Jingjing
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev
2014-08-28 09:01, Wu, Jingjing:
> I have another question:
> If we use the way 'rx_classification_filter_ctl' works, the specific
> structures defined in rte_i40e.h will be visible in user's application,
> such as testpmd.
> I know I shouldn't make commands linked with i40e like what I did before.
sorry, just depreciate it, I post it in the wrong list :-)
On Thu, Aug 28, 2014 at 12:56 PM, loy wolfe wrote:
> newest ovs support using native linux tunnel tx/rx api, and linux kernel
> up to 3.14, which has gso/gro merged for udp tunnel. I remember someone
> submitted this patch has attained
newest ovs support using native linux tunnel tx/rx api, and linux kernel up
to 3.14, which has gso/gro merged for udp tunnel. I remember someone
submitted this patch has attained 12Gbps for linux vxlan tcp, so are there
any performance data for ovs vxlan tcp?
2014-08-28 03:30, Wu, Jingjing:
> We want to implement several common API for NIC specific features,
> to avoid creating quite a lot of ops in 'struct eth_dev_ops'.
> The idea came from ioctl.
The approach can be interesting.
> Because about flow director feature, there is large gap between i40e
On Wed, Aug 27, 2014 at 07:18:44PM +, Ananyev, Konstantin wrote:
>
>
> > -Original Message-
> > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > Sent: Wednesday, August 27, 2014 7:57 PM
> > To: Ananyev, Konstantin
> > Cc: dev at dpdk.org; thomas.monjalon at 6wind.com
> > Subjec
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Thursday, August 28, 2014 11:56 AM
> To: Wu, Jingjing
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API
> rx_classification_filter_ctl
>
> 20
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Thursday, August 28, 2014 12:01 PM
> To: Wu, Jingjing
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 7/7]app/testpmd: add commands and config
> functions for i40e flow director support
>
> 2014-08-28 09:
2014-08-28 08:41, Richardson, Bruce:
> As for rte_rdtsc_precise, I'm not sure about its origins, but I'm
> surprised to see that it does not correspond to the rdtscp instruction.
> Can anyone else comment on this one? I would assume it's designed
> to be used to get more accurate measurements of sm
Hi Thomas,
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Thursday, August 28, 2014 4:37 PM
> To: Liu, Jijiang
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 3/7]rte_ether:add API of VxLAN packet filter
> in librte_ether
>
> 2014-08-2
2014-08-28 03:39, Wu, Jingjing:
> Because these macros such as IPPROTO_TCP, IPPROTO_UDP are already
> defined in . If user's application include
> and rte_ip.h at the same time, there will be conflict error, for
> example cmdline.c in testpmd.
Yes
> I remember there was someone also raised this
2014-08-28 03:51, Wu, Jingjing:
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > 2014-08-27 10:13, Jingjing Wu:
> > > add structure definition to construct programming packet.
> >
> > What is a "programming packet"?
>
> For Fortville, we need to set a flow director filter by send
2014-08-28 00:55, Liu, Jijiang:
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > I wonder if we could use a common function to set all kind of filters?
> >
> > Thoughts are welcome.
>
> The rte_eth_dev_tunnel_filter_set() is a common filter function for
> tunneling packet, which
2014-08-28 01:33, Liu, Jijiang:
> > > lib/librte_ether/rte_ethdev.c | 63
> > > lib/librte_ether/rte_ethdev.h | 76 ++
> > > lib/librte_ether/rte_ether.h | 10 ++
> > > lib/librte_pmd_i40e/i40e_ethdev.c | 199
> >
> > Changing ethdev API is so sensible
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Thursday, August 28, 2014 10:06 AM
> To: Richardson, Bruce
> Cc: Cyril Chemparathy; dev at dpdk.org
> Subject: Re: [dpdk-dev] next releases
>
> 2014-08-28 08:41, Richardson, Bruce:
> > As for rte_rd
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ananyev, Konstantin
> Sent: Wednesday, August 27, 2014 8:19 PM
> To: Neil Horman
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCHv3] librte_acl make it build/work for 'default'
> target
>
>
>
> > -Or
Hi, Thomas
Thanks for your tips.
I have another question:
If we use the way 'rx_classification_filter_ctl' works, the specific structures
defined in rte_i40e.h will be visible in user's application, such as testpmd.
I know I shouldn't make commands linked with i40e like what I did before. But
w
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Cyril Chemparathy
> Sent: Wednesday, August 27, 2014 6:05 PM
> To: Thomas Monjalon; dev at dpdk.org
> Subject: Re: [dpdk-dev] next releases
>
> Hi Thomas,
>
> On 8/25/2014 10:15 AM, Thomas Monjalon wrote:
> > H
Hi Matthew,
On Aug 27, 2014, at 10:00 PM, Matthew Hall wrote:
> On Wed, Aug 27, 2014 at 03:13:43PM +, Wiles, Roger Keith wrote:
>> Hi Everyone,
>
> Hi Keith,
>
> For me the build failed with clang but I made a series of awful patches to
> get
> it to compile... not sure if the clang fail
PMD is combined of 'PM' - a thread model and 'D' - a user space driver.
DPDK provides optimized RX and TX in Driver on fast path.
DPDK provides a single thread core affinity model to demonstrate the best IO
with minimum noisy penalty.
They are not tight coupling as Venky said.
In some cases, you
Hi, Thomas
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, August 27, 2014 10:36 PM
> To: Wu, Jingjing
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 7/7]app/testpmd: add commands and config
> functions for
> i40e flow direc
Hi, Thomas
Because these macros such as IPPROTO_TCP, IPPROTO_UDP are already defined in
. If user's application include and rte_ip.h at
the same time, there will be conflict error, for example cmdline.c in testpmd.
I remember there was someone also raised this issue few month ago.
So just use t
HI, Thomas
Just as zhang, helin's said in his pacth "[dpdk-dev] [PATCH 2/5] ethdev: add
new ops of 'check_command_supported' and 'rx_classification_filter_ctl'":
'rx_classification_filter_ctl' is for receive classification filter
configuring. e.g. hash function configuration, flow director conf
Hi, Thomas
I will rework on it.
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, August 27, 2014 10:25 PM
> To: Wu, Jingjing
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 3/7] i40e: function implement in i40e for
> flow dir
Hi, Thomas
The "flow director resource" means we need to reserve a specific queue and VSI
on HW to support. The queue and vsi is used for programming flow director
filter, not common tx/rx queues.
2 separated items, one is about setup, another is for release. I will try to
separate them.
> -
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, August 27, 2014 10:59 PM
> To: Liu, Jijiang
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 1/7]i40e:support VxLAN packet
> identification
>
> Hi Jijiang,
>
> 2014-08-26 15:31
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, August 27, 2014 11:12 PM
> To: Liu, Jijiang
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 3/7]rte_ether:add API of VxLAN packet filter
> in librte_ether
>
> 2014-08-26 15:31,
52 matches
Mail list logo
