Hey,
I observe continuous burst of I/O Errors, as indicated below, with the testpmd
application with DPDK 1.7.1.This seems to originate from
eal_intr_process_interrupts() function. I seemed to have setup the DPDK
prerequisites alright.
Another recent post seemed to suggest moving back to 1.7.0,
2014-10-11 13:55, Jijiang Liu:
> Support VxLAN Tx checksum offload, which include
> - outer L3(IP) checksum offload
> - inner L3(IP) checksum offload
> - inner L4(UDP, TCP and SCTP) checksum offload
[...]
> +
> + /* fields to support tunnelling packet TX offloads */
I know that previous
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Friday, October 17, 2014 12:07 AM
> To: Wu, Jingjing
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] filter_ctl PMD API idea
>
> 2014-09-08 15:06, Wu, Jingjing:
> > Any comments or advises?
> >
> >
This test report brings a lot of details. It's a good thing but we should
find a way to remove the "administrative words".
It should start with the tested-by line to allow copy paste in the commit log.
2014-10-11 07:56, Liu, Yong:
> Patch name: Support VxLAN on Fortville
> Brief descript
I don't review the common API as it should be done in an unique place
and there are many copies in different patchsets. Let's focus on tunnels.
2014-10-11 13:55, Jijiang Liu:
> +/ TUNNEL FILTER DATA DEFINATION *** */
We cannot miss this comment :)
> +#define ETH_TUNNEL_FILTER_OMAC 0x01
> +#
2014-10-11 13:55, Jijiang Liu:
> - "tx_checksum set mask (port_id)\n"
> + "tx_checksum set (mask) (port_id)\n"
> "Enable hardware insertion of checksum offload with"
> - " the 4-bit mask, 0~0xf, in packets sent on
2014-10-11 13:55, Jijiang Liu:
> #
> +# Compile tunneling UDP port support
> +#
> +CONFIG_RTE_LIBRTE_TUNNEL_UDP_PORT=4789
> +
> +#
1) this option is not to "Compile tunneling UDP port support"
2) why is it a compile time option? should it be an API parameter or
a runtime option?
> + uint16_t
On 2014/10/16 19:45, Walukiewicz, Miroslaw wrote:
> I have a question regarding unbinding Linux interface from EAL.
>
> This feature was present up to dpdk 1.4 and next it was removed.
>
> It was available under RTE_EAL_UNBIND_PORTS flag.
>
> Is there a possibility to get this feature back in t
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Alan Carew
> Sent: Tuesday, October 14, 2014 1:19 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] librte_eal: FreeBSD contigmem prevent
> possible buffer overrun during module unload.
>
> The maximum mo
2014-10-11 13:55, Jijiang Liu:
> Add data structures and APIs in librte_ether for supporting tunneling UDP
> port configuration on i40e,
> Currently, only VxLAN is implemented, which include
> - VxLAN UDP port initialization
> - Add APIs to configure VxLAN UDP port
Please could you explain in
Hi Cristian,
2014-06-04 19:08, Cristian Dumitrescu:
> This library provides a tool to interpret config files that have standard
> structure.
>
> It is used by the Packet Framework examples/ip_pipeline sample application.
>
> It originates from examples/qos_sched sample application and now it mak
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Alan Carew
> Sent: Sunday, October 12, 2014 8:36 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v4 04/10] VM Power Management application
> and Makefile.
>
> For launching CLI thread and Monitor thread
From: "Chen Jing D(Mark)"
1. Function i40e_vsi_* name change to i40e_dev_* since PF can contains
more than 1 VSI after VMDQ enabled.
2. i40e_dev_rx/tx_queue_setup change to have capability of setup
queues that belongs to VMDQ pools.
3. Add queue mapping. This will do a convertion between qu
From: "Chen Jing D(Mark)"
Change i40e_macaddr_add and i40e_macaddr_remove functions to support
multiple macaddr add/delete. In the meanwhile, support macaddr ops
on different pools.
Signed-off-by: Chen Jing D(Mark)
---
lib/librte_pmd_i40e/i40e_ethdev.c | 89 +-
From: "Chen Jing D(Mark)"
The change includes several parts:
1. Get maximum number of VMDQ pools supported in dev_init.
2. Fill VMDQ info in i40e_dev_info_get.
3. Setup VMDQ pools in i40e_dev_configure.
4. i40e_vsi_setup change to support creation of VMDQ VSI.
Signed-off-by: Chen Jing D(Mark)
-
From: "Chen Jing D(Mark)"
Assign new VMDQ arguments with correct values.
Signed-off-by: Chen Jing D(Mark)
---
lib/librte_pmd_ixgbe/ixgbe_ethdev.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
From: "Chen Jing D(Mark)"
Assign new VMDQ arguments with correct values.
Signed-off-by: Chen Jing D(Mark)
---
lib/librte_pmd_e1000/igb_ethdev.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/lib/librte_pmd_e1000/igb_ethdev.c
b/lib/librte_pmd_e1000/igb_ethdev.c
inde
From: "Chen Jing D(Mark)"
The change includes several parts:
1. Clear pool bitmap when trying to remove specific MAC.
2. Define RSS, DCB and VMDQ flags to combine rx_mq_mode.
3. Use 'struct' to replace 'union', which to expand the rx_adv_conf
arguments to better support RSS, DCB and VMDQ.
4. F
From: "Chen Jing D(Mark)"
v2:
- Fix a few typos.
- Add comments for RX mq mode flags.
- Remove '\n' from some log messages.
- Remove 'Acked-by' in commit log.
v1:
Define extra VMDQ arguments to expand VMDQ configuration. This also
includes change in igb and ixgbe PMD driver. In the meanwhile, fi
2014-09-08 15:06, Wu, Jingjing:
> Any comments or advises?
>
> Thanks!
>
> Fortville Filter features' development will be started based on this design
> this week.
Thanks Jingjing for explaining your plan before working on it.
There were no comment for 1 month so we'll assume everybody is OK.
2014-10-10 07:28, De Lara Guarch, Pablo:
> > > > > Define new APIs to support configure multi-kind filters using same
> > > > > APIs
> > > > > - rte_eth_dev_filter_supported
> > > > > - rte_eth_dev_filter_ctrl
> > > > >
> > > > > As to the implemetation discussion, please refer to
> > > > > http:
Hi Thomas,
> > However with a DPDK solution it would be possible to re-use the message bus
> > to pass information like device stats, application state, D-state requests
> > etc. to the host and allow for management layer(e.g. OpenStack) to make
> > informed decisions.
>
> I think that management
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jijiang Liu
> Sent: Saturday, October 11, 2014 6:56 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v5 4/8]librte_ether:add a common filter API
>
> Introduce a new filter framewok in librte_ether. As to
I have a question regarding unbinding Linux interface from EAL.
This feature was present up to dpdk 1.4 and next it was removed.
It was available under RTE_EAL_UNBIND_PORTS flag.
Is there a possibility to get this feature back in the next releases?
Unbinding interfaces from EAL makes possible
Konstantin,
In my understanding, compiler barrier is a kind of software barrier which
prevents the compiler from moving memory accesses across the barrier. This
should be architecture-independent. And the "sync" instruction is a
hardware barrier which depends on PowerPC architecture. So I think
> -Original Message-
> From: Richardson, Bruce
> Sent: Thursday, October 16, 2014 10:43 AM
> To: Chao CH Zhu; Ananyev, Konstantin
> Cc: dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power
> architecture
>
> > -Original Message-
> > From: d
>
>
> From: Chao CH Zhu [mailto:bjzhuc at cn.ibm.com]
> Sent: Thursday, October 16, 2014 4:14 AM
> To: Ananyev, Konstantin
> Cc: dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power
> architecture
>
> Konstantin,
>
> In my understanding, compiler barrie
On 2014/10/15 18:08, Richardson, Bruce wrote:
>
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Lilijun
>> Sent: Wednesday, October 15, 2014 10:43 AM
>> To: dev at dpdk.org; stephen at networkplumber.org
>> Subject: Re: [dpdk-dev] kernel panic when stop
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of De Lara Guarch,
> Pablo
> Sent: Monday, October 13, 2014 5:13 PM
> To: Liu, Jijiang; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v5 2/8]i40e:support VxLAN packet
> identification in librte_pmd_i40e
>
>
>
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Chao CH Zhu
> Sent: Thursday, October 16, 2014 4:14 AM
> To: Ananyev, Konstantin
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power
> architecture
>
> Konstantin,
>
> -Original Message-
> From: Lilijun [mailto:jerry.lilijun at huawei.com]
> Sent: Thursday, October 16, 2014 3:40 AM
> To: Richardson, Bruce; dev at dpdk.org; stephen at networkplumber.org
> Subject: Re: [dpdk-dev] kernel panic when stop my test demo
>
> On 2014/10/15 18:08, Richardson,
This patch splits CPU flags related operations from DPDK and push them
to architecture specific arch directories, so that other processor
architecture can implement it's own CPU flag functions to support DPDK.
Signed-off-by: Chao Zhu
---
lib/librte_eal/common/Makefile |4
This patch splits the SSE based memory copy function from DPDK and push
them to architecture specific arch directories. Other processor
architecture can implement it's own vector based memory copy functions.
Signed-off-by: Chao Zhu
---
lib/librte_eal/common/Makefile |4 +-
This patch splits the spinlock operations from DPDK and push them to
architecture specific arch directories, so that other processor
architecture to support DPDK can be easily adopted.
Signed-off-by: Chao Zhu
---
lib/librte_eal/common/Makefile |4 +-
.../common/include/ar
This patch splits the prefetch operations from DPDK and push them to
architecture specific arch directories, so that other processor
architecture to support DPDK can implement their own functions.
Signed-off-by: Chao Zhu
---
lib/librte_eal/common/Makefile |4 +-
.../commo
This patch splits the CPU TSC read operations from DPDK and push them to
architecture specific arch directories, so that other processors that
don't have tsc register can be can implement its'own functions.
Signed-off-by: Chao Zhu
---
lib/librte_eal/common/Makefile |4 +-
This patch splits the byte order operations from DPDK and push them to
architecture specific arch directories, so that other processor
architecture to support DPDK can be easily adopted.
Signed-off-by: Chao Zhu
---
lib/librte_eal/common/Makefile |4 +-
.../common/include/
This patch first add architecture specific directories to eal header
file directory. Then split the atomic operations to architecture specific and
generic files. Architecture specific files are put into the
corresponding architecture directory and common header are put into
generic directory.
Sign
The set of patches split x86 architecture specific operations from DPDK and put
them to the
arch directories of i686 and x86_64 architecture. This will make the adpotion
of DPDK much easier
on other computer architecture. For a new architecture, just add an
architecture specific
directory and ne
On Oct 15, 2014, at 1:46 PM, daniel chapiesky wrote:
> I just watched the closing remarks by Tim Driscol at the dpdk summit
>
> http://youtu.be/r-JA5NBybrs
>
> At time 4:30, he mentioned the "shock to the system" of developers
> expecting a pat on the back and instead receiving critiques o
> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Thursday, October 16, 2014 12:01 AM
> To: Liu, Jijiang; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v5 4/8]librte_ether:add a common filter API
>
>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk
Hi Thomas
Thank you very much for the detailed guidance! It is really helpful for me.
Regards,
Helin
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, October 15, 2014 8:22 PM
> To: Zhang, Helin
> Cc: dev at dpdk.org; Liu, Jijiang
> Sub
Hi Thomas
Yes, your proposal it the perfect one, also the most complicated one. I was
thinking of that one as well, but we did not have enough time for that in our
1.8 timeframe.
In the long run, I agree with you to implement EAL function to access PCI
config space directly. I will try to put i
Hi,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Chao Zhu
> Sent: Friday, September 26, 2014 10:36 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power
> architecture
>
> The atomic operations implemented with
44 matches
Mail list logo
