> -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
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
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
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
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 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
>
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:
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 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
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
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
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
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.
>
>> 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:
> * 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,
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:
> 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
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
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:
> 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
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:
> 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:
> 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:
> 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
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
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
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
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
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
> 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 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
31 matches
Mail list logo
