On Tue, Sep 09, 2014 at 06:47:48AM +, Zhang, Helin wrote:
> That means your great works under GPL/LGPL license will not occur in DPDK
> main line, as it is always BSD license.
>
> Regards,
> Helin
However despite this issue, there are some cases where the Linux stack is
greatly superior to
> On Sep 8, 2014, at 11:20 PM, Matthew Hall wrote:
>
> On Tue, Sep 09, 2014 at 08:49:44AM +0800, zimeiw wrote:
>> 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.
>
> He
On Tue, Sep 09, 2014 at 08:49:44AM +0800, zimeiw wrote:
> 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.
Hello,
This is awesome work to be doing and badly needed to use DP
I would use it :)
It's useful to store the IP protocol number (UDP, TCP etc) and version
of IP (4, 6) and then relay packet to specific handler.
08.09.2014 16:17, Olivier MATZ ?:
> Hi Bruce,
>
> On 09/03/2014 05:49 PM, Bruce Richardson wrote:
>> Replace a reserved slot with the new packet type
Any comments or advises?
Thanks!
Fortville Filter features' development will be started based on this design
this week.
> -Original Message-
> From: Wu, Jingjing
> Sent: Thursday, September 4, 2014 8:05 PM
> To: dev at dpdk.org
> Cc: stephen at networkplumber.org; vincent.jardin at 6w
Hi Bruce,
On 08/27/2014 05:50 PM, Bruce Richardson wrote:
> 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 in
Hi Bruce,
On 09/03/2014 05:49 PM, Bruce Richardson wrote:
> This change splits the mbuf in two to move the pool and next pointers to
> the second cache line. This frees up 16 bytes in first cache line.
>
> Signed-off-by: Bruce Richardson
I think you should provide more explanation in the commit
On 09/03/2014 05:49 PM, Bruce Richardson wrote:
> Add markers or "labels" at given points inside the mbuf which can be
> used instead of individual fields to identify the start of logical
> sections inside the mbuf.
>
> The use of typedefs and dummy fields was chosen over using unions
> because of
Hi Bruce,
On 09/03/2014 05:49 PM, Bruce Richardson wrote:
> Removed the explicit zero-sized metadata definition at the end of the
> mbuf data structure. Updated the metadata macros to take account of this
> change so that all existing code which uses those macros still works.
>
> Signed-off-by: B
On 09/03/2014 05:49 PM, Bruce Richardson wrote:
> * Ensure comments line up correctly
> * Simplify the #ifdefs around the refcnt fields to make them clearer
>
> Signed-off-by: Bruce Richardson
Acked-by: Olivier Matz
Hi Bruce,
On 09/03/2014 05:49 PM, Bruce Richardson wrote:
> Since the flags field is now 64-bits, we can allow one bit to be used to
> indicate a control i.e. non-packet mbuf. Dedicate the high bit (bit 63)
> for this purpose and add in a utility macro to test if a given mbuf has
> the bit set or
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 reserved1; /**< Unused field. Required for padding */
>>>
>
Hi Bruce,
On 09/03/2014 05:49 PM, Bruce Richardson wrote:
> The offload flags field (ol_flags) was 16-bits and had no further room
> for expansion. This patch increases the field size to 64-bits, using up
> the remaining reserved space in the single-cache-line mbuf.
>
> NOTE: none of the values f
Hi Bruce,
On 09/03/2014 05:49 PM, Bruce Richardson wrote:
> Replace a reserved slot with the new packet type field used to identify
> the type of the packet, i.e. what protocols are used.
>
> Signed-off-by: Bruce Richardson
> ---
> lib/librte_mbuf/rte_mbuf.h | 2 +-
> 1 file changed, 1 insertio
Hi Bruce,
On 09/03/2014 05:49 PM, Bruce Richardson wrote:
> * Reorder the fields in the mbuf so that we have fields that are used$
> together side-by-side in the structure. This means that we have a$
> contiguous block of 8-bytes in the mbuf which are used to reset an mbuf$
> of descriptor rearm,
>> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
>> index 32e8474..669e7f5 100644
>> --- a/lib/librte_mbuf/rte_mbuf.h
>> +++ b/lib/librte_mbuf/rte_mbuf.h
>> @@ -119,6 +119,13 @@ struct rte_mbuf {
>> void *buf_addr; /**< Virtual address of segment buffer. */
>>
Hi Bruce,
On 09/03/2014 05:49 PM, Bruce Richardson wrote:
> From: Olivier Matz
>
> Original patch:
> The mbuf structure already contains a pointer to the beginning of the
> buffer (m->buf_addr). It is not needed to use 8 bytes again to store
> another pointer to the beginning of the data.
>
Hi Bruce,
Just small typos below.
On 08/28/2014 05:42 PM, Bruce Richardson wrote:
> 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 pa
On 08/28/2014 05:42 PM, Bruce Richardson wrote:
> 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:
> * Furt
On 09/04/2014 03:25 PM, Bruce Richardson wrote:
> 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 th
Hi Bruce,
On 08/28/2014 05:42 PM, Bruce Richardson wrote:
> 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
>
On 08/28/2014 05:42 PM, Bruce Richardson wrote:
> 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
Hello Bruce,
On 08/28/2014 05:42 PM, Bruce Richardson wrote:
> 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 m
Hi,
I've been using the PMD pcap driver for a while now. It's very handy for
testing and running DPDK on systems with no Intel NICs (like my laptop).
Unfortunately I've found a small issue that's been bothering me a lot.
It turns out that the PMD pcap driver opens the pcaps/interfaces only at
Thank you Anatoly !
I?ll do that and get back in case of questions.
Regards,
-Sujith
On 08/09/14 2:00 pm, "Burakov, Anatoly" wrote:
>Hi Sujith
>
>Of course you can. Just use the igb_uio driver instead. Refer to the
>Getting Started Guide from Intel, it'll walk you through the steps,
>although t
Hi Sujith
Of course you can. Just use the igb_uio driver instead. Refer to the Getting
Started Guide from Intel, it'll walk you through the steps, although they are
basically the same as for VFIO.
Thanks,
Anatoly
-Original Message-
From: Sujith Sankar (ssujith) [mailto:ssuj...@cisco.co
Anatoly,
Thanks for the quick response !
I am able do PCI passthrough and use the NIC in the guest OS.
What I?m trying to do is run DPDK in the guest and make use of the
passed-through NIC. Without using VFIO, could I achieve this?
Thanks,
-Sujith
On 08/09/14 1:51 pm, "Burakov, Anatoly" wrote:
Hi Sujith
Not that I know of, no. There are other ways to run physical NICs in a VM
though, you don't require VFIO for that.
Thanks,
Anatoly
-Original Message-
From: Sujith Sankar (ssujith) [mailto:ssuj...@cisco.com]
Sent: Monday, September 8, 2014 9:20 AM
To: Burakov, Anatoly; Stephen
Hi Anatoly,
Has anything happened in this front? Do you see running of DPDK in guest
OS on KVM with physical NIC passed through to it happening soon?
Thanks,
-Sujith
On 02/05/14 2:28 pm, "Burakov, Anatoly" wrote:
>Hi Stephen,
>
>> Will this work in guest? or only on bare metal?
>
>VFIO is Li
Bruce,
That's tremendously helpful. Thanks for the information.
--
Matt Laswell
*infinite io*
On Sun, Sep 7, 2014 at 2:52 PM, Richardson, Bruce <
bruce.richardson at intel.com> wrote:
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Matt Laswell
> > S
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Friday, August 29, 2014 17:41
> To: dev at dpdk.org
> Cc: Wodkowski, PawelX
> Subject: Re: [dpdk-dev] [PATCH] ixgbe_rx_scan_hw_ring: Fix initializing id and
> hash fields in flow director mode.
>
> H
31 matches
Mail list logo
