hi,
I have porting major FreeBSD tcp/ip stack to dpdk. new tcp/ip stack is based
on dpdk rte_mbuf, rte_ring, rte_memory and rte_table. it is faster to
forwarding packets.
Below feature are ready:
Netdp initialize
Ether layer
ARP
IP layer
Routing
ICMP
Commands for adding, deleting, showing IP
Hi Olivier,
> -Original Message-
> From: Zhu, Heqing
> Sent: Tuesday, September 09, 2014 9:48 AM
> To: Wu, Jingjing; Liu, Jijiang; Zhang, Helin
> Cc: Zhu, Heqing
> Subject: FW: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field
>
> One of you need respond to this thread? Please make the
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier MATZ
> Sent: Monday, September 8, 2014 7:17 PM
> To: Yerden Zhumabekov; Richardson, Bruce; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field
>
> Hi Yerden,
>
> On 09/
Hi,
I have a question about initialization order in rte_eal_init()
It seems some lcore related functions are called between
rte_eal_dev_init(PMD_INIT_PRE_PCI_PROBE) and rte_eal_pci_probe().
Is there any reason to do so?
int
rte_eal_init(int argc, char **argv)
{
(snip)
if (rte_eal_dev_init(PMD_I
I've ported the Linux kernel TCP/IP stack to user space and integrated with
DPDK, the source and documentation and the roadmap will be published (and
announced) within few days.
Regards,
Vadim
On Sep 9, 2014 9:20 AM, "Matthew Hall" wrote:
> On Tue, Sep 09, 2014 at 08:49:44AM +0800, zimeiw wrote:
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vadim Suraev
> Sent: Tuesday, September 9, 2014 2:30 PM
> To: Matthew Hall
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] TCP/IP stack for DPDK
>
> I've ported the Linux kernel TCP/IP stack to user space and
IMHO, since GPL is more restrictive so the source must remain open
On Sep 9, 2014 9:39 AM, "Zhang, Helin" wrote:
>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vadim Suraev
> > Sent: Tuesday, September 9, 2014 2:30 PM
> > To: Matthew Hall
> > Cc: de
? That means your great works under GPL/LGPL license will not occur in DPDK
main line, as it is always BSD license.
Regards,
Helin
From: Vadim Suraev [mailto:vadim.sur...@gmail.com]
Sent: Tuesday, September 9, 2014 2:43 PM
To: Zhang, Helin
Cc: Matthew Hall; dev at dpdk.org
Subject: RE: [dpdk-dev
Here is the update of i40e base driver. Also it involves a few
relevant necessary code changes in i40e PMD.
Helin Zhang (15):
i40e: make the indentation more consistent in share code
i40e: support nvmupdate by default
i40e: remove useless code which was written for Solaris
i40e: remove tes
In share code, 'tab' is used to align values rather than 'space'.
The changes in i40e_adminq_cmd.h is to make the indentation more
consistent in share code.
Signed-off-by: Helin Zhang
Reviewed-by: Chen Jing
---
lib/librte_pmd_i40e/i40e/i40e_adminq_cmd.h | 2132 ++--
1 fi
'nvmupdate' is intended to support the userland NVMUpdate tool for
Fortville eeprom. These code changes is to remove the conditional
compile macro, and support those by default. In addition, renaming
all 'errno' to avoid any compile warning or error.
Signed-off-by: Helin Zhang
Reviewed-by: Chen J
The code wrapped in '#ifdef DMA_SYNC_SUPPORT' was written specially
for Solaris, it is not needed anymore for others including DPDK.
Signed-off-by: Helin Zhang
Reviewed-by: Chen Jing
---
lib/librte_pmd_i40e/i40e/i40e_adminq.c | 19 ---
1 file changed, 19 deletions(-)
diff --git
The code wrapped in '#ifdef ETHTOOL_TEST' in i40e_diag.c is for
ethtool testing only, it is not needed anymore and can be removed.
Signed-off-by: Helin Zhang
Reviewed-by: Chen Jing
---
lib/librte_pmd_i40e/i40e/i40e_diag.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/lib/librte
There are variables that represent values in little endian.
Adding prefix of '__Le' can remove warnings during sparse
checks. In addition, remove some unreachable 'break' statements,
and add 'UL' on a couple of constants.
Signed-off-by: Helin Zhang
Reviewed-by: Chen Jing
---
lib/librte_pmd_i40e
The code wrapped in '#ifdef I40E_DCB_SW' is currently for software
validation only, it should be removed at all.
Signed-off-by: Helin Zhang
Reviewed-by: Chen Jing
---
lib/librte_pmd_i40e/i40e/i40e_common.c| 27 --
lib/librte_pmd_i40e/i40e/i40e_dcb.c | 625
The firware api request of writes to hardware registers should be
exposed to driver. The new API of 'i40e_aq_debug_write_register'
is introduced for that.
Signed-off-by: Helin Zhang
Reviewed-by: Chen Jing
---
lib/librte_pmd_i40e/i40e/i40e_common.c| 29 +
lib/libr
The workaround helps fix the API if the FW is 4.2 or later.
In addition, an unreachable 'break' statement has been removed.
Signed-off-by: Helin Zhang
Reviewed-by: Chen Jing
---
lib/librte_pmd_i40e/i40e/i40e_adminq.c | 5 ++---
lib/librte_pmd_i40e/i40e/i40e_common.c | 12 ++--
2 files
As struct of 'i40e_arq_event_info' in share code has
been redefined, relevant changes in PMD are needed to
support that.
Signed-off-by: Helin Zhang
Reviewed-by: Chen Jing
---
lib/librte_pmd_i40e/i40e_ethdev.c| 8 +++-
lib/librte_pmd_i40e/i40e_ethdev_vf.c | 10 +-
2 files change
The fix is to use get_link_status but not get_phy_capabilities
for reporting FC settings.
Signed-off-by: Helin Zhang
Reviewed-by: Chen Jing
---
lib/librte_pmd_i40e/i40e/i40e_common.c | 38 --
lib/librte_pmd_i40e/i40e/i40e_type.h | 8 ---
2 files changed, 1
Force a shifted '1' to be 'unsiged' to avoid shifting a signed int.
Signed-off-by: Helin Zhang
Reviewed-by: Chen Jing
---
lib/librte_pmd_i40e/i40e/i40e_hmc.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/lib/librte_pmd_i40e/i40e/i40e_hmc.h
b/lib/librte_pmd_i40e/i40e/
The code wrapped in '#ifdef PREBOOT_SUPPORT' was added for
queue context initialization specifically for A0 silicon.
As A0 silicon has gone for a long time, the code should be
removed at all. In addition, the checks of 'QV_RELEASE'
and 'PREBOOT_SUPPORT' are also not needed anymore and can
be remove
The code wrapped in '#ifdef I40E_TPH_SUPPORT' was added
to check if 'TPH' is supported, and enable it. It is not
used currently and can be removed.
Signed-off-by: Helin Zhang
Reviewed-by: Chen Jing
---
lib/librte_pmd_i40e/i40e/i40e_common.c | 55 --
1 file change
10G base T type support is added.
Signed-off-by: Helin Zhang
Reviewed-by: Chen Jing
---
lib/librte_pmd_i40e/i40e/i40e_common.c | 3 +++
lib/librte_pmd_i40e/i40e/i40e_type.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/lib/librte_pmd_i40e/i40e/i40e_common.c
b/lib/librte_pmd_i40e/i40e
Overloading the 'msg_size' field in the 'arq_event_info' struct
is a bad idea. It leads to bugs when the structure is used in a
loop, since the input value (buffer size) is overwritten by the
output value (actual message length). The fix introduces one
more field of 'buf_len' for the buffer size, a
hi,
netdp stack use rte_mbuf directly, so no packet copied from DPDK port queue to
netdp stack. netdp forwarding performance is same as FreeBSD.
At 2014-09-09 02:20:16, "Matthew Hall" wrote:
>On Tue, Sep 09, 2014 at 08:49:44AM +0800, zimeiw wrote:
>> I have porting major FreeBSD tcp/ip st
Hello,
On 09/09/2014 05:59 AM, Zhang, Helin wrote:
> It is a common field which i40e PMD will use it to store the 'packet type
> ID'. i40e
> hardware can recognize more than a hundred of packet types of received
> packets,
> this is quite useful for upper layer stack or application. So this fiel
>-Original Message-
>From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of rong wen
>Sent: Saturday, September 6, 2014 8:07 PM
>To: dev
>Subject: [dpdk-dev] dpdk 1.6 insmod rte_kni.ko error
>
>Hi All,
>
>I am a new guy to use dpdk. The kernel version is 2.6.32.
>
>After I build the rte_kn
> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Tuesday, September 9, 2014 4:03 PM
> To: Zhang, Helin; Yerden Zhumabekov; Richardson, Bruce; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field
>
> Hello,
>
> On 09/09/2
> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Monday, September 08, 2014 9:22 AM
> To: Richardson, Bruce; dev at dpdk.org
> Subject: Re: [PATCH v2 3/6] mbuf: remove rte_ctrlmbuf
>
> Hi Bruce,
>
> On 08/28/2014 05:42 PM, Bruce Richardson wrote:
> > Fr
> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Monday, September 08, 2014 11:26 AM
> To: Richardson, Bruce; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 04/13] mbuf: expand ol_flags field to 64-bits
>
> Hi Bruce,
>
> On 09/03/2014 05:49 PM, Bruce
> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Monday, September 08, 2014 1:06 PM
> To: Richardson, Bruce; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 07/13] mbuf: use macros only to access the
> mbuf metadata
>
> Hi Bruce,
>
> On 09/03/2014 05:4
> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Monday, September 08, 2014 1:33 PM
> To: Richardson, Bruce; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 0/6] Mbuf structure Rework, part 1
>
> Hi Bruce,
>
> On 08/27/2014 05:50 PM, Bruce Richardson
> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Tuesday, September 09, 2014 9:03 AM
> To: Zhang, Helin; Yerden Zhumabekov; Richardson, Bruce; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field
>
> Hello,
>
> On 09/09/
Hello,
I was looking at the code which inits rte_hash objects in examples/l3fwd. It's
using approx. 1M to 4M hash 'entries' depending on 32-bit vs 64-bit, but it's
setting the 'bucket_entries' to just 4.
Normally I'm used to using somewhat deeper hash buckets than that... it seems
like having
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Matthew Hall
> Sent: Tuesday, September 09, 2014 11:32 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] Defaults for rte_hash
>
> Hello,
>
> I was looking at the code which inits rte_hash objects in examples/l3fw
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Richardson, Bruce
> Sent: Tuesday, September 09, 2014 11:45 AM
> To: Matthew Hall; dev at dpdk.org
> Subject: Re: [dpdk-dev] Defaults for rte_hash
>
> > -Original Message-
> > From: dev [mailto:dev-bou
Matthew Hall wrote:
> However despite this issue, there are some cases where the Linux stack is
> greatly superior to the BSD one although normally the opposite is the case...
> AF_NETLINK for configuring 10,000+ IP addresses, especially for L4-L7
> performance testing, would be one possible exa
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
Porting Linux stack to DPDK opens up a licensing can of worms.
Linux code is GPLv2, and DPDK code is BSD. Any combination of the two would
end up
being covered by the Linux GPLv2 license.
On Mon, Sep 8, 2014 at 11:30 PM, Vadim Suraev
wrote:
> I've ported the Linux kernel TCP/IP stack to user spa
> On Sep 9, 2014, at 5:16 AM, Alexander Nasonov wrote:
>
> Matthew Hall wrote:
>> However despite this issue, there are some cases where the Linux stack is
>> greatly superior to the BSD one although normally the opposite is the
>> case...
>> AF_NETLINK for configuring 10,000+ IP addresses, e
> On Sep 8, 2014, at 4:17 AM, Olivier MATZ wrote:
>
> Hi Yerden,
>
> On 09/08/2014 12:33 PM, Yerden Zhumabekov wrote:
>> 08.09.2014 16:17, Olivier MATZ ?:
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -146,7 +146,7 @@ struct rte_mbuf {
uint32_t
The licensing worms prevent IMHO only selling the source code, although,
porting may be useful
On Sep 9, 2014 5:54 PM, "Stephen Hemminger"
wrote:
> Porting Linux stack to DPDK opens up a licensing can of worms.
> Linux code is GPLv2, and DPDK code is BSD. Any combination of the two
> would end up
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Tuesday, September 09, 2014 3:41 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v3 6/6] mbuf: flatten struct vlan_macip into
> mbuf struct
>
> The vlan_macip structure combined
Then you don?t understand licensing.
the GPL has a requirement that you make one of two offers:
The fourth section for version 2 of the license and the seventh section of
version 3 require that programs distributed as pre-compiled binaries are
accompanied by a copy of the source code, or a wri
#You can?t sell the source, you have to make it available, either with the
binary, or to anyone who asks#
But I didn't tell I want to sell it, and I open all the source
On Sep 9, 2014 6:26 PM, "Jim Thompson" wrote:
> Then you don?t understand licensing.
>
> the GPL has a requirement that you mak
On Tue, Sep 09, 2014 at 08:49:44AM +0800, zimeiw wrote:
> hi,
>
>
> I have porting major FreeBSD tcp/ip stack to dpdk. new tcp/ip stack is based
> on dpdk rte_mbuf, rte_ring, rte_memory and rte_table. it is faster to
> forwarding packets.
>
> Below feature are ready:
>
> Netdp initialize
> E
Jim Thompson wrote:
> BPF JIT, or even pflua[1] should be straight-forward to put on top of DPDK.
> (It?s straight-forward to do on top of netmap.)
>
> jim
>
> [1] https://github.com/Igalia/pflua-bench
Glad to see LuaJIT here. I hope to DPDK will eventually add support for
LuaJIT.
Alex
On Tue, Sep 09, 2014 at 11:42:40AM +, De Lara Guarch, Pablo wrote:
> That 4 is not shifted, so it is actually 4 entries/bucket. Actually, the
> maximum number of entries you can use is 16, as bucket will be as big as a
> cache line. However, regardless the number of entries, memory size will
On Tue, Sep 09, 2014 at 07:54:19AM -0700, Stephen Hemminger wrote:
> Porting Linux stack to DPDK opens up a licensing can of worms.
> Linux code is GPLv2, and DPDK code is BSD. Any combination of the two would
> end up
> being covered by the Linux GPLv2 license.
It would be a can of worms for a cl
On Tue, Sep 09, 2014 at 08:00:32AM -0700, Jim Thompson wrote:
> BPF JIT, or even pflua[1] should be straight-forward to put on top of DPDK.
> (It?s straight-forward to do on top of netmap.)
>
> jim
The pflua guys made a user-space copy of Linux BPF JIT. I'm planning to use
that because it was
Matthew Hall wrote:
> The pflua guys made a user-space copy of Linux BPF JIT. I'm planning to use
> that because it was almost as fast as pflua with a lot fewer usage headaches
> and dependencies.
Ah, I see.
> I'm making an MIT licensed app... so it isn't an issue for me personally if
> there
On Tue, Sep 09, 2014 at 10:30:01PM +0100, Alexander Nasonov wrote:
> sys/net/bpfjit.c in NetBSD should be very easy to adapt to Linux.
> I was often testing it on Linux in userspace (without mbuf support).
> At the moment, I'm only allowed to work on some NetBSD projects and
> I can't adapt bpfjit
Matthew Hall wrote:
> Alex,
>
> You rock, thanks for supplying this, I'll be sure to use it along with
> upstream changes from BSD to get a friendlier license for users of my code,
> whoever they might eventually be.
>
> If I forked this from you and updated it to the latest code periodically f
53 matches
Mail list logo
