Acked-by: Jingjing Wu
> -Original Message-
> From: Zhang, Helin
> Sent: Thursday, April 30, 2015 11:04 PM
> To: dev at dpdk.org
> Cc: Cao, Min; Xu, Qian Q; Wu, Jingjing; Liu, Jijiang; Kenguva, Monica; Patel,
> Rashmin N; Murray, Steven J; Nelson, Shannon; Zhang, Helin
> Subject: [PATCH v
Acked-by: Jingjing Wu
> -Original Message-
> From: Zhang, Helin
> Sent: Thursday, April 30, 2015 11:03 PM
> To: dev at dpdk.org
> Cc: Cao, Min; Xu, Qian Q; Wu, Jingjing; Liu, Jijiang; Kenguva, Monica; Patel,
> Rashmin N; Murray, Steven J; Nelson, Shannon; Zhang, Helin
> Subject: [PATCH v2
Acked-by: Jingjing Wu
> -Original Message-
> From: Zhang, Helin
> Sent: Thursday, April 30, 2015 11:03 PM
> To: dev at dpdk.org
> Cc: Cao, Min; Xu, Qian Q; Wu, Jingjing; Liu, Jijiang; Kenguva, Monica; Patel,
> Rashmin N; Murray, Steven J; Nelson, Shannon; Zhang, Helin
> Subject: [PATCH v2
Acked-by: Jingjing Wu
> -Original Message-
> From: Zhang, Helin
> Sent: Thursday, April 30, 2015 11:03 PM
> To: dev at dpdk.org
> Cc: Cao, Min; Xu, Qian Q; Wu, Jingjing; Liu, Jijiang; Kenguva, Monica; Patel,
> Rashmin N; Murray, Steven J; Nelson, Shannon; Zhang, Helin
> Subject: [PATCH v
Acked-by: Jingjing Wu
> -Original Message-
> From: Zhang, Helin
> Sent: Thursday, April 30, 2015 11:03 PM
> To: dev at dpdk.org
> Cc: Cao, Min; Xu, Qian Q; Wu, Jingjing; Liu, Jijiang; Kenguva, Monica; Patel,
> Rashmin N; Murray, Steven J; Nelson, Shannon; Zhang, Helin
> Subject: [PATCH v2
Acked-by: Jingjing Wu
> -Original Message-
> From: Zhang, Helin
> Sent: Thursday, April 30, 2015 11:03 PM
> To: dev at dpdk.org
> Cc: Cao, Min; Xu, Qian Q; Wu, Jingjing; Liu, Jijiang; Kenguva, Monica; Patel,
> Rashmin N; Murray, Steven J; Nelson, Shannon; Zhang, Helin
> Subject: [PATCH v
Acked-by: Jingjing Wu
> -Original Message-
> From: Zhang, Helin
> Sent: Thursday, April 30, 2015 11:03 PM
> To: dev at dpdk.org
> Cc: Cao, Min; Xu, Qian Q; Wu, Jingjing; Liu, Jijiang; Kenguva, Monica; Patel,
> Rashmin N; Murray, Steven J; Nelson, Shannon; Zhang, Helin
> Subject: [PATCH v
Acked-by: Jingjing Wu
> -Original Message-
> From: Zhang, Helin
> Sent: Thursday, April 30, 2015 11:03 PM
> To: dev at dpdk.org
> Cc: Cao, Min; Xu, Qian Q; Wu, Jingjing; Liu, Jijiang; Kenguva, Monica; Patel,
> Rashmin N; Murray, Steven J; Nelson, Shannon; Zhang, Helin
> Subject: [PATCH v2
On 5/7/15, 9:05 AM, "Avi Kivity" wrote:
>On 05/07/2015 06:49 PM, Wiles, Keith wrote:
>>
>> On 5/7/15, 8:33 AM, "Avi Kivity" wrote:
>>
>>> On 05/07/2015 06:27 PM, Wiles, Keith wrote:
On 5/7/15, 7:02 AM, "Avi Kivity" wrote:
> On Wed, Apr 22, 2015 at 6:11 PM, O'Driscoll, Tim
>
Hi Luke
On 5/7/15, 8:34 AM, "Luke Gorrie" wrote:
>On 7 May 2015 at 16:02, Avi Kivity wrote:
>
>> One problem we've seen with dpdk is that it is a framework, not a
>>library:
>> it wants to create threads, manage memory, and generally take over.
>>This
>> is a problem for us, as we are writing a
On 8 May 2015 at 06:16, Wiles, Keith wrote:
> The PMDs or drivers would not be useful without DPDK MBUFS IMO
>
Surprisingly perhaps, I would find them very useful.
To me there are two parts to a driver: the hardware setup and the
transmit/receive.
The hardware setup is complex and generic. You
Acked-By: Jijiang Liu
> -Original Message-
> From: Zhang, Helin
> Sent: Thursday, April 30, 2015 11:03 PM
> To: dev at dpdk.org
> Cc: Cao, Min; Xu, Qian Q; Wu, Jingjing; Liu, Jijiang; Kenguva, Monica; Patel,
> Rashmin N; Murray, Steven J; Nelson, Shannon; Zhang, Helin
> Subject: [PATCH v2
The following changes since commit cddae880b69155f76efa3241d02437fc69fade45:
ixgbe: use scattered Rx with bulk allocation (2015-05-07 19:19:18 +0200)
are available in the git repository at:
helin at dpdk.org:dpdk-i40e-next.git master
for you to fetch changes up to c73e796e3b1c15ac8ae66a0c18
On Fri, May 08, 2015 at 07:29:39AM +0200, Luke Gorrie wrote:
> On 8 May 2015 at 06:16, Wiles, Keith wrote:
>
> > The PMDs or drivers would not be useful without DPDK MBUFS IMO
> >
>
> Surprisingly perhaps, I would find them very useful.
>
> To me there are two parts to a driver: the hardware se
On Thu, May 07, 2015 at 10:11:15PM +0100, Wiles, Keith wrote:
>
>
> On 5/7/15, 9:04 AM, "Bruce Richardson" wrote:
>
> >On Thu, May 07, 2015 at 05:45:20PM +0200, Marc Sune wrote:
> >>
> >>
> >> On 07/05/15 17:35, Bruce Richardson wrote:
> >> >The "lib" directory is getting very crowded, with b
Hi Bruce,
On 8 May 2015 at 11:06, Bruce Richardson wrote:
> For the Intel NIC drivers, the hardware setup part used in DPDK is based
> off
> the other Intel drivers for other OS's. The code you are interested in
> should
> therefore be contained within the subfolders off each individual PMD. As
On Fri, May 08, 2015 at 11:32:04AM +0200, Luke Gorrie wrote:
> Hi Bruce,
>
> On 8 May 2015 at 11:06, Bruce Richardson
> wrote:
>
> > For the Intel NIC drivers, the hardware setup part used in DPDK is based
> > off
> > the other Intel drivers for other OS's. The code you are interested in
> > sh
On 8 May 2015 at 11:42, Bruce Richardson wrote:
> The code in those directories is "common" code that is maintained by Intel
> -
> which is why you see repeated comments about not modifying it for DPDK. It
> is
> just contained in it's own subfolder in each DPDK driver for easier
> updating
> off
> Sounds like you want something like libc, but DPDK is a system like a user
> space OS more then it is a collection of functions that are independent
> like strlen, strcpy, memcpy, printf or ... Some parts of DPDK are
> independent and can be used as you suggest, but the real performance
> sectio
On Fri, May 08, 2015 at 12:26:39PM +0200, Hobywan Kenoby wrote:
>
> > Sounds like you want something like libc, but DPDK is a system like a user
> > space OS more then it is a collection of functions that are independent
> > like strlen, strcpy, memcpy, printf or ... Some parts of DPDK are
> > ind
Hi Luke,
On 5/7/15, 10:29 PM, "Luke Gorrie" wrote:
>On 8 May 2015 at 06:16, Wiles, Keith wrote:
>
>The PMDs or drivers would not be useful without DPDK MBUFS IMO
>
>
>
>
>
>Surprisingly perhaps, I would find them very useful.
>
>
>To me there are two parts to a driver: the hardware setup and th
Hi Andrey,
OK, so be it. Thus in case you want to distribute (or just calculate hash
based on non standart tuple) - use your own tuple and own hash key (length
of tuple and key - responsible of the programmer). In case you want to
emulate NIC RSS - use union rte_thash_tuple (still needs to be upda
Software implementation of the Toeplitz hash function used by RSS.
Can be used either for packet distribution on single queue NIC
or for simulating of RSS computation on specific NIC (for example
after GRE header decapsulating).
v3 changes
- Rework API to be more generic
- Add sctp_tag into tuple
On Fri, 8 May 2015 14:44:17 +
"Wiles, Keith" wrote:
> Hi Luke,
>
> On 5/7/15, 10:29 PM, "Luke Gorrie" wrote:
>
> >On 8 May 2015 at 06:16, Wiles, Keith wrote:
> >
> >The PMDs or drivers would not be useful without DPDK MBUFS IMO
> >
> >
> >
> >
> >
> >Surprisingly perhaps, I would find the
On Fri, 8 May 2015 09:31:34 -0400
Neil Horman wrote:
> On Fri, May 08, 2015 at 12:26:39PM +0200, Hobywan Kenoby wrote:
> >
> > > Sounds like you want something like libc, but DPDK is a system like a user
> > > space OS more then it is a collection of functions that are independent
> > > like str
Please NOTE that this series is meant to illustrate an idea/approach and start
discussion on the topic.
Current implemetation allows reserving/creating memzones but not the opposite
(unreserve/delete). This affects mempools and other memzone based objects.
>From my point of view, implementing unr
In the current memory hierarchy, memsegs are groups of physically contiguous
hugepages, memzone are slices of memsegs and malloc further slices memzones
into smaller memory chunks.
This patch modifies malloc so it slices/partitions memsegs instead of memzones.
Thus memzones would call malloc inter
This patch moves the malloc library inside the eal.
This is the first step towards using malloc to allocate memory directly
from memsegs. Thus, memzones would allocate memory through malloc,
allowing unreserve/free memzones.
Signed-off-by: Sergio Gonzalez Monroy
---
config/common_bsdapp
Background:
After preliminary discussion with John (Zhihong) and Tim from Intel it was
decided that it would be beneficial to use AVX/SSE instructions for memcmp
similar to memcpy being implemeneted. In addition, we decided to use
librte_hash as a test candidate to test both functionality and perfo
This patch replaces memcmp in librte_hash with rte_memcmp which is
implemented with AVX/SSE instructions.
Preliminary results on Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz, Ubuntu
14.04 x86_64 shows comparisons using AVX/SSE instructions taking 1/3rd
CPU ticks for 16, 32, 48 and 64 bytes comparison.
On Fri, May 8, 2015 at 4:19 PM, Ravi Kerur wrote:
> This patch replaces memcmp in librte_hash with rte_memcmp which is
> implemented with AVX/SSE instructions.
>
> +static inline int
> +rte_memcmp(const void *_src_1, const void *_src_2, size_t n)
> +{
> + const uint8_t *src_1 = (const uint8
On Fri, May 8, 2015 at 3:29 PM, Matt Laswell wrote:
>
>
> On Fri, May 8, 2015 at 4:19 PM, Ravi Kerur wrote:
>
>> This patch replaces memcmp in librte_hash with rte_memcmp which is
>> implemented with AVX/SSE instructions.
>>
>> +static inline int
>> +rte_memcmp(const void *_src_1, const void *_s
Any inputs here? No functionality change just cleanup. I have run "make
test" and "memcpy_perf_autotest". I have not noticed any changes in numbers.
On Mon, Apr 20, 2015 at 1:33 PM, Ravi Kerur wrote:
> Remove unnecessary type casting in functions.
>
> Tested on Ubuntu (14.04 x86_64) with "make t
On Fri, May 8, 2015 at 5:54 PM, Ravi Kerur wrote:
>
>
> On Fri, May 8, 2015 at 3:29 PM, Matt Laswell
> wrote:
>
>>
>>
>> On Fri, May 8, 2015 at 4:19 PM, Ravi Kerur wrote:
>>
>>> This patch replaces memcmp in librte_hash with rte_memcmp which is
>>> implemented with AVX/SSE instructions.
>>>
>>>
34 matches
Mail list logo
