I think iopl() was added to have permission to do Port I/O for Virtio device
handling.
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Xie, Huawei
Sent: Wednesday, August 27, 2014 2:22 AM
To: David Marchand; dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH RFC 0/3] o
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 failures could be related to your
scan-build failures. If it will help you I can pro
> -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
> Subject: Re: [PATCHv3] librte_acl make it build/work for 'default' target
>
> On Wed, Aug
> It's here:
> https://scan.coverity.com
>
> Some checks have been done with TrustInSoft Analyzer:
> http://dpdk.org/ml/archives/dev/2014-May/002365.html
> Noticeable example:
> http://dpdk.org/browse/dpdk/commit/?id=2612a4b935144accff
Registered on coverity, anyone for the admi
Hi Helin,
2014-07-28 16:25, Helin Zhang:
> For better understanding, 'PCTYPE' which represents
> 'Packet Classification Type' is used to replace 'RSS'
> in the name of shift macros.
I have the same comments as for VF RSS serie, since it's almost
the same patch ;)
--
Thomas
2014-08-27 15:52, Wiles, Roger Keith:
> I groped around on the Coverity site and did not find any statement about
> being free to open source, but I may have just missed it.
It's here:
https://scan.coverity.com
Some checks have been done with TrustInSoft Analyzer:
http://dpdk.org/
Hi all!
I took a look at the scan-results from Keith to compare with my analysis. My
analysis is on test-pmd (called with a specific command-line and with start
tx_first at the prompt) and scans exhaustively for all undefined behaviors
(overflow, division by zero, invalid pointer dereference or
2014-07-18 10:45, Helin Zhang:
> improvements for some macro definition about RSS packet
> classification types in rte_ethdev.h.
[...]
> -#define ETH_RSS_IPV4((uint16_t)1 << ETH_RSS_IPV4_SHIFT)
[...]
> +#define ETH_RSS_IPV4(1 << ETH_RSS_IPV4_SHIFT)
Please ex
2014-07-18 10:45, Helin Zhang:
> i40e can support RSS no matter if SR-IOV is enabled or not, while
> ixgbe/igb can not support RSS if it is SR-IOV. Code changes are
> needed to support i40e RSS if SR-IOV is enabled.
[...]
> - /* In SR-IOV mode, RSS mode is not available */
> -
Acked-by: Huawei Xie
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of David Marchand
> Sent: Tuesday, August 26, 2014 10:12 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH RFC 2/3] eal: don't call rte_eal_iopl_init
> unconditionnally
>
> There is no ne
2014-08-26 15:31, Jijiang Liu:
> +enum rte_tunnel_filter_type {
> + RTE_TUNNEL_FILTER_TYPE_NONE = 0,
> + RTE_TUNNEL_FILTER_IMAC_IVLAN, /**< Filter by inner MAC and VLAN ID. */
> + RTE_TUNNEL_FILTER_IMAC_IVLAN_TENID,
> + /**< Filter by inner MAC address and VLAN ID, tenned ID. */
> +
Hi Jijiang,
2014-08-26 15:31, Jijiang Liu:
> VxLAN UDP port configuration on i40e, which include
> - VxLAN UDP port initialization
> - add APIs to configure VxLAN UDP port
Actually you should explain that you introduce tunnels
and first one is VxLAN.
> lib/librte_ether/rte_ethdev.c |
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
---
lib/librte_pmd_i
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.
Signed-off-by: Bruce Richardson
---
examples/dpdk_qat/main.c
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
Hi Jingjing,
2014-08-27 10:13, Jingjing Wu:
> add structure definition to construct programming packet.
What is a "programming packet"?
> +#ifdef RTE_LIBRTE_I40E_PMD
> + "i40e_flow_director_filter (port_id) (add|del)"
> + " flow (ip4|ip6) src (src_ip_addre
2014-08-27 10:13, Jingjing Wu:
> fix the Marco conflict between rte_ip.h and netinet/in.h
Who is Marco?
> +#ifndef _NETINET_IN_H
> +#ifndef _NETINET_IN_H_
> /* IPv4 protocols */
> #define IPPROTO_IP 0 /**< dummy for IP */
> #define IPPROTO_HOPOPTS0 /**< IP6 hop-by-hop options */
2014-08-27 10:13, Jingjing Wu:
> support the API ops defined in ethdev, the behavior according to each command:
> RTE_CMD_FDIR_RULE_ADD: add a new FDIR filter rule.
> RTE_CMD_FDIR_RULE_DEL: delete a FDIR filter rule.
Here title is really too complicated. Be concise.
I'd change it to:
i
Hi Jingjing,
2014-08-27 10:13, Jingjing Wu:
> support a new ethdev API rx_classification_filter_ctl for all
> the configuration or queries for receive classification filters.
> this patch supports commands the API used below:
> RTE_CMD_FDIR_RULE_ADD
> RTE_CMD_FDIR_RULE_DEL
> RTE_CMD_FDIR_FLU
Not sure why cite marks are missing again :-( I hope they come back some day. I
still must not have Mac Mail configure correctly, but I only really see a
couple of options. If someone has a solution let me know.
On Aug 27, 2014, at 11:09 AM, Thomas Monjalon
wrote:
> 2014-08-27 15:52, Wiles, R
Hi Jingjing,
I don't understand the title. What is a "flow director resource"?
2014-08-27 10:13, Jingjing Wu:
> flow director resource reserve and initialize on i40e, it includes
> - queue initialization and switch on and vsi creation during setup
> - queue vsi for flow director release during
When I have time maybe next month, will submit my initial RFC patch to enable
interrupt and polling mode switching for 10G NIC with sample. Welcome anybody
in the community to further optimize it.
I think it will be very hard to have a generic DPDK-NAPI API to fit all the use
cases, at least th
Nice, we had to buy one and that was not cheap :-) I groped around on the
Coverity site and did not find any statement about being free to open source,
but I may have just missed it.
I did find that PC-Lint, Coverity, scan-build, ? all seem to test different
parts of your code and some are bett
Hi Everyone,
I built dpdk with Clang and used the scan-build analyzer to produce a report.
The report is about 13M in size so not very nice to send to the list. I decided
to place the report on github.com if you want to see the results.
While running scan-build the build would fail, but I force
Yes. Iopl is to allow out from user space. I played with ioperm instead but
that is per thread and was a nuisance.
Hi Ouyang,
(2014/08/27 15:00), Ouyang, Changchun wrote:
> Yes, it doesn't matter which one is faster for virtio device creation
> and destroy, as it is not in data path.
I agree with you.
Thanks,
Tetsuya
>> Thanks,
>> Tetsuya
>>
>>
>>> Regards,
>>> Changchun
>>>
-Original Message-
Hi Xie,
(2014/08/27 14:56), Xie, Huawei wrote:
> For virtio-net device driver, there is still no difference. Existing
> solution creates an eventfd module to install a fd in DPDK process
> pointing to the eventfd in qemu process. In vhost-user, the UNIX
> domain socket will do that work, create a
(2014/08/27 14:27), Tetsuya.Mukawa wrote:
> Hi Changchun,
>
> (2014/08/27 14:01), Ouyang, Changchun wrote:
>> Agree with you, the performance should be same as the data path (RX/TX) is
>> not affected,
>> The difference between implementation only exists in the virtio device
>> creation and destr
On Wed, Aug 27, 2014 at 11:25:04AM +, Ananyev, Konstantin wrote:
> > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > Sent: Tuesday, August 26, 2014 6:45 PM
> > To: Ananyev, Konstantin
> > Cc: dev at dpdk.org; thomas.monjalon at 6wind.com
> > Subject: Re: [PATCHv3] librte_acl make it bui
Hi Changchun,
(2014/08/27 14:01), Ouyang, Changchun wrote:
> Agree with you, the performance should be same as the data path (RX/TX) is
> not affected,
> The difference between implementation only exists in the virtio device
> creation and destroy stage.
Yes, I agree. Also There may be the diffe
(2014/08/27 9:43), Ouyang, Changchun wrote:
> Do we have performance comparison between both implementation?
Hi Changchun,
If DPDK applications are running on both guest and host side, the
performance should be almost same, because while transmitting data virt
queues are accessed by virtio-net PM
Hi Huawei,
2014-08-27 10:09, Xie, Huawei:
> ok, as long as we ensure with virtio PMD, the parent DPDK process has the
> iopl permission so that all child threads inherits the permission.
If you think the patch serie is ok, a "Reviewed-by" would be appreciated.
Also, please could you check your e
On Wed, Aug 27, 2014 at 11:57 AM, Xie, Huawei wrote:
> That is ok. If virtio PMD is a dynamic linked library, is it possible
> that virtio PMD is loaded later?
>
The shared library are loaded through -d option, which are loaded just
before the call to rte_eal_dev_init().
--
David Marchand
>
Hi all,
Yesterday, during Hot Interconnects in Google?s Mountain View Headquarters,
has been announced the winners of the DPDK SPEED MATTERS contest,
sponsored by 6WIND.
We get three winners:
AEPONYX, TrustInSoft and Srivats P.
They won nice RC cars running at more than 50 km/h (not for
IMHO adding "Interrupt Mode" to dpdk is important as this can open
DPDK to a larger public of consumers, I can easily imagine someone
trying to find user space networking solution (And deciding against
verbs - RDMA) for the obvious reasons and not needing deterministic
latency.
A few thoughts:
D
Hello,
On Wed, Aug 27, 2014 at 11:22 AM, Xie, Huawei wrote:
> Hi David:
> The reason iopl is put in rte_eal_init is that we want all later created
> DPDK processes/threads inherit the iopl permission.
> If you only call iopl in pmd_init, RX/TX and other threads which needs io
> permission will s
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Tuesday, August 26, 2014 6:45 PM
> To: Ananyev, Konstantin
> Cc: dev at dpdk.org; thomas.monjalon at 6wind.com
> Subject: Re: [PATCHv3] librte_acl make it build/work for 'default' target
>
> On Mon, Aug 25, 2014 at 04:30:05PM +, Ana
On Wed, Aug 27, 2014 at 08:13:59AM +, Abdul Rasheed Shaik wrote:
>
> Hello,
>
> DPDK doesnt compile with MACHINE---> ivshmem.
>
> I tried to compile DPDK on FreeBSD Guest machine.
> gmake install T=x86_64-ivshmem-bsdapp-gcc CC=gcc48
> I get the following error
> ,,,
> ,,,
> Build app
> Build
On Tue, Aug 26, 2014 at 04:10:41PM +0200, David Marchand wrote:
> No need for that 'x bit' on source files.
>
> Signed-off-by: David Marchand
Acked-by: Bruce Richardson
> ---
> 0 files changed
> mode change 100755 => 100644 examples/l3fwd/main.c
> mode change 100755 => 100644 examples/qos_m
On Wed, 27 Aug 2014 08:53:46 -0500
Jay Rolette wrote:
> The updated output is definitely an improvement, but if you'll go with the
> first solution you described (adding \n in the log macro), it works much
> better for products using DPDK. For developer use, I think it ends up being
> a wash eith
On Wed, 27 Aug 2014 05:42:09 +
"Ouyang, Changchun" wrote:
>
> > -Original Message-
> > From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> > Sent: Wednesday, August 27, 2014 12:24 AM
> > To: Ouyang, Changchun
> > Cc: dev at dpdk.org
> > Subject: Re: [RFC 06/10] virtio: u
Here's the link you want: https://scan.coverity.com/
Check the FAQ for terms and you'll need to register the product, but I
didn't see anything obvious that should get in the way from being able to
use it for DPDK.
Agree with Coverity not being cheap. I bought it for my last company.
Really liked
Hello,
I wrote a code that creates some KNI interfaces, destroys them when some
management events occur, and creates new interfaces when other
management events happen.
What happens is that I create a number of interfaces using "kni_alloc",
I destroy ALL of them through "kni_release" and, when I
Hi Stephen,
> Some drivers need ability to access PCI config (for example for power
> management). This
> adds an abstraction to do this; only implemented on Linux, but should be
> possible on BSD.
Since VFIO has to go to PCI config space too for some things, could you please
amend your patch
*> We could run something like PC-Lint or Coverity, but they cost money :-)*
Pretty sure Coverity is free for open source projects...
Jay
On Wed, Aug 27, 2014 at 10:13 AM, Wiles, Roger Keith <
keith.wiles at windriver.com> wrote:
> Hi Everyone,
>
> I built dpdk with Clang and used the scan-build
add structure definition to construct programming packet.
add commands to programming 6 flow types for the flow director filters,
which is called PCTYPE in fortville: ipv4, tcpv4, udpv4, ipv6, tcpv6, udpv6
add commands to support flushing flow director table and get info
Signed-off-by: jingjing.wu
support to get the fdir_match counter
support to set the FDIR flag and FD_ID reported in mbuf
Signed-off-by: jingjing.wu
Reviewed-by: Helin Zhang
Reviewed-by: Jing Chen
Reviewed-by: Jijiang Liu
---
lib/librte_pmd_i40e/i40e_ethdev.c | 5
lib/librte_pmd_i40e/i40e_rxtx.c | 49 ++
fix the Marco conflict between rte_ip.h and netinet/in.h
Signed-off-by: jingjing.wu
Reviewed-by: Helin Zhang
Reviewed-by: Jing Chen
Reviewed-by: Jijiang Liu
---
lib/librte_net/rte_ip.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lib/librte_net/rte_ip.h b/lib/librt
support the API ops defined in ethdev, the behavior according to each command:
RTE_CMD_FDIR_FLUSH : clear all FDIR filter rules.
RTE_CMD_FDIR_INFO_GET: get FDIR information.
Signed-off-by: jingjing.wu
Reviewed-by: Helin Zhang
Reviewed-by: Jing Chen
Reviewed-by: Jijiang Liu
---
lib/libr
support the API ops defined in ethdev, the behavior according to each command:
RTE_CMD_FDIR_RULE_ADD: add a new FDIR filter rule.
RTE_CMD_FDIR_RULE_DEL: delete a FDIR filter rule.
Signed-off-by: jingjing.wu
Reviewed-by: Helin Zhang
Reviewed-by: Jing Chen
Reviewed-by: Jijiang Liu
---
lib/
support a new ethdev API rx_classification_filter_ctl for all
the configuration or queries for receive classification filters.
this patch supports commands the API used below:
RTE_CMD_FDIR_RULE_ADD
RTE_CMD_FDIR_RULE_DEL
RTE_CMD_FDIR_FLUSH
RTE_CMD_FDIR_INFO_GET
Signed-off-by: jingjing.wu
R
flow director resource reserve and initialize on i40e, it includes
- queue initialization and switch on and vsi creation during setup
- queue vsi for flow director release during close
Signed-off-by: jingjing.wu
Reviewed-by: Helin Zhang
Reviewed-by: Jing Chen
Reviewed-by: Jijiang Liu
---
l
The patch set supports flow director programming on fortville.
It includes:
- reserve i40e resources for flow director, such as queue and vsi.
- support the new ethdev API rx_classification_filter_ctl for all
the configuration or queries for receive classification filters.
- support programmi
ok, as long as we ensure with virtio PMD, the parent DPDK process has the iopl
permission so that all child threads inherits the permission.
From: David Marchand [mailto:david.march...@6wind.com]
Sent: Wednesday, August 27, 2014 6:05 PM
To: Xie, Huawei
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev
Hi Thomas,
On 8/25/2014 10:15 AM, Thomas Monjalon wrote:
> Hello all,
>
> I am back from holidays; thanks for all the
> patches/reviews/comments done during last weeks.
>
> I'd like to have a version 1.7.1, ideally at the end of this week.
>
> For the coming days,
> - first priority is to inte
That is ok. If virtio PMD is a dynamic linked library, is it possible that
virtio PMD is loaded later?
From: David Marchand [mailto:david.march...@6wind.com]
Sent: Wednesday, August 27, 2014 5:34 PM
To: Xie, Huawei
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH RFC 0/3] only call iopl when ne
On 8/27/2014 7:35 AM, Thomas Monjalon wrote:
> Hi Jingjing,
>
> 2014-08-27 10:13, Jingjing Wu:
>> add structure definition to construct programming packet.
> What is a "programming packet"?
>
>> +#ifdef RTE_LIBRTE_I40E_PMD
>> +"i40e_flow_director_filter (port_id) (add|del)"
>>
Hi David:
The reason iopl is put in rte_eal_init is that we want all later created DPDK
processes/threads inherit the iopl permission.
If you only call iopl in pmd_init, RX/TX and other threads which needs io
permission will segmentation fault.
-huawei
> -Original Message-
> From: dev [
Hi David,
The updated output is definitely an improvement, but if you'll go with the
first solution you described (adding \n in the log macro), it works much
better for products using DPDK. For developer use, I think it ends up being
a wash either way.
At least for my product (embedded network ap
Tested-by: Liu, Yong < yong.liu at intel.com>
This patch set has been verified and ready to integrated into dpdk.org.
Please refer to following information:
Board: CrownPass
OS: Fedora20
Kenrel: 3.15.8-200.fc20.x86_64
GCC: gcc version 4.8.3
NIC: Fortville Spirit Falls
VxLAN cases
Hello,
DPDK doesnt compile with MACHINE---> ivshmem.
I tried to compile DPDK on FreeBSD Guest machine.
gmake install T=x86_64-ivshmem-bsdapp-gcc CC=gcc48
I get the following error
,,,
,,,
Build app
Build app/test
CC test_ivshmem.o
/root/dpdk-1.7.0/app/test/test_ivshmem.c:49:25: fatal error:rte_i
DPDK currently isn't exactly poll mode - it has an API that receives and
transmits packets. How you enter that API could be interrupt or polled
-we've left that up to the application to decide, rather than force a
interrupt/NAPI type architecture. I do agree with Alex in that
implementing a int
Hello, folks:
I only see the rte_mempool_create but without function like
rte_mempool_destroy? If I run an application twice, is there possible that the
app has the memory leak? Or it just doesn't have enough memory to execute it
again because the first one already get most of the memory but
> -Original Message-
> From: Tetsuya.Mukawa [mailto:mukawa at igel.co.jp]
> Sent: Wednesday, August 27, 2014 1:28 PM
> To: Ouyang, Changchun; dev at dpdk.org
> Cc: Xie, Huawei; Katsuya MATSUBARA; nakajima.yoshihiro at lab.ntt.co.jp;
> Hitoshi Masutani
> Subject: Re: [dpdk-dev] [RFC] lib/l
> -Original Message-
> From: Tetsuya.Mukawa [mailto:mukawa at igel.co.jp]
> Sent: Wednesday, August 27, 2014 1:28 PM
> To: Ouyang, Changchun; dev at dpdk.org
> Cc: Xie, Huawei; Katsuya MATSUBARA; nakajima.yoshihiro at lab.ntt.co.jp;
> Hitoshi Masutani
> Subject: Re: [dpdk-dev] [RFC] lib/l
You're right and I've felt the same harder part of determinism with other
hypervisors' soft switch solutions as well. I think it's worth thinking about.
Thanks,
Rashmin
On Aug 26, 2014 9:15 PM, Stephen Hemminger
wrote:
The way to handle switch between out of poll mode is to use IRQ coalescing
> -Original Message-
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Wednesday, August 27, 2014 12:24 AM
> To: Ouyang, Changchun
> Cc: dev at dpdk.org
> Subject: Re: [RFC 06/10] virtio: use software vlan stripping
>
> On Tue, 26 Aug 2014 08:37:11 +
> "Ouyang,
Hi Tetsuya
Thanks for your response.
Agree with you, the performance should be same as the data path (RX/TX) is not
affected,
The difference between implementation only exists in the virtio device creation
and destroy stage.
Regards,
Changchun
> -Original Message-
> From: Tetsuya.Mukaw
On Wed, Aug 27, 2014 at 07:46:26AM +, Ni, Xun wrote:
> If I run an application twice, is there possible that
> the app has the memory leak? Or it just doesn't have enough memory to
> execute it again because the first one already get most of the memory but
> without release it.
User-mapped
Do we have performance comparison between both implementation?
Thanks
Changchun
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Xie, Huawei
Sent: Tuesday, August 26, 2014 7:06 PM
To: dev at dpdk.org
Subject: Re: [dpdk-dev] [RFC] lib/librte_vhost: qemu vhost-user su
Hi,
On Tue, Aug 26, 2014 at 08:55:29PM +, Habibi, Michael wrote:
> I have verified in our kernel source, as well as the public
> source for 2.6.34, that irq_to_desc is not an exported function.
> However the documentation states that the minimum version required is
> only 2.6.33. Did I setup m
76 matches
Mail list logo
