increase MAX_QUEUES from 256 to 512
In vhost example, MAX_QUEUES macro should be the maximum possible queue number
of the port.
Theoretically we should only set up the queues that are used, i.e., first rx
queue of each pool, or
at most queues from 0 to MAX_QUEUES. Before we revise the implementat
Hi Michael:
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Qiu, Michael
> Sent: Monday, December 08, 2014 8:28 AM
> To: Burakov, Anatoly; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4] VFIO: Avoid to enable vfio while the module
> not loaded
>
> On 20
Hi Michael,
> -Original Message-
> From: Qiu, Michael
> Sent: Wednesday, December 10, 2014 12:03 AM
> To: Ouyang, Changchun; Richardson, Bruce
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [RFC PATCH 00/17] Single virtio implementation
>
> On 2014/12/9 22:19, Ouyang, Changchun wrote:
>
In the current codes, the "tx_checksum set (ip|udp|tcp|sctp|vxlan) (hw|sw)
(port-id)" command is not easy to understand and extend, so the patch set
enhances the tx_checksum command and reworks csum forwarding engine due to the
change of tx_checksum command.
The main changes of the tx_checksum
If the flag is set in a PMD, which means the NIC(s) support TX checksum offload
of tunneling packet.
Signed-off-by: Jijiang Liu
---
lib/librte_ether/rte_ethdev.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.
The DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM flag is added in i40e capability set, which
means the i40e supports TX checksum offload of tunneling packet.
Signed-off-by: Jijiang Liu
---
lib/librte_pmd_i40e/i40e_ethdev.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/lib/librte
The patch enhances the tx_checksum command and reworks csum forwarding engine
due to the change of tx_checksum command.
The main changes of the tx_checksum command are listed below,
1. add "tx_checksum set tunnel (hw|sw|none) (port-id)" command
2. add "tx_checksum set outer-ip (hw|sw) (port-id)"
On 12/10/2014 8:17 AM, Xie, Huawei wrote:
> Hi Michael:
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Qiu, Michael
>> Sent: Monday, December 08, 2014 8:28 AM
>> To: Burakov, Anatoly; dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH v4] VFIO: Avoid to en
When vfio module is not loaded when kernel support vfio feature,
the routine still try to open the container to get file
description.
This action is not safe, and of cause got error messages:
EAL: Detected 40 lcore(s)
EAL: unsupported IOMMU type!
EAL: VFIO support could not be initialized
EAL:
When the first address is the compared address in the loop,
it will also do memory copy, which is meaningless,
worse more, when hugepg_tbl is mostly in order. This should
be a big deal in large hugepage memory systerm(like hunderd
or thousand GB).
Meanwhile smallest_idx never be a value of -1,so r
strict_strtoul() was just a redefinition of kstrtoul() for a long
time. From kernel version of 3.18, strict_strtoul() will not be
defined at all. A compile time kernel version check is needed to
decide which function or macro can be used for a specific version
of kernel.
Signed-off-by: Helin Zhang
Here is my patch for it, and it also resolves issue of pci_num_vf()
definition.
And I will send V3 for a while.
On 12/10/2014 10:38 AM, Helin Zhang wrote:
> strict_strtoul() was just a redefinition of kstrtoul() for a long
> time. From kernel version of 3.18, strict_strtoul() will not be
> defi
Hi Jincheng
Did you attach anything? I can see the text only.
Could you forward your patch mail to me directly? Thanks a lot!
Regards,
Helin
> -Original Message-
> From: Jincheng Miao [mailto:jmiao at redhat.com]
> Sent: Wednesday, December 10, 2014 10:55 AM
> To: Zhang, Helin; dev at dp
There is a bug in querying reta, of storing the data to the correct entry.
Code changes is straightforward for this bug.
Signed-off-by: Helin Zhang
---
lib/librte_pmd_i40e/i40e_ethdev.c| 2 +-
lib/librte_pmd_i40e/i40e_ethdev_vf.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
v2 c
>From upstream kernel commit 3db2e9cd, strict_strto* serial functions
are removed. So that we should directly used kstrtoul instead.
Kstrtoul exists from RHEL6.4, so for compatible with old kernel and RHEL,
add some logic to igb_uio/compat.h, same as what we do for pci_num_vf().
Signed-off-by: Ji
>From upstream kernel commit 3db2e9cd, strict_strto* serial functions
are removed. So that we should directly used kstrtoul instead.
And add kni/compat.h for be compatible with older kernel.
Signed-off-by: Jincheng Miao
---
lib/librte_eal/linuxapp/kni/compat.h| 16
lib/li
>From upstream kernel commit 3db2e9cd, strict_strto* serial functions
are removed. So that we should directly used kstrtoul instead.
And add xen_dom0/compat.h for be compatible with older kernel.
Signed-off-by: Jincheng Miao
---
lib/librte_eal/linuxapp/xen_dom0/compat.h | 16 +++
On 12/10/2014 11:02 AM, Zhang, Helin wrote:
> Hi Jincheng
>
> Did you attach anything? I can see the text only.
> Could you forward your patch mail to me directly? Thanks a lot!
Hi Helin,
I indeed ever saw one patch that was similar this one :) but not sure if
it is post by Jincheng.
You can go
Hi Thomas,
What's going on with this patch?
I really do not have other better solution.
Thanks,
Michael
On 12/8/2014 9:30 AM, Qiu, Michael wrote:
> On 12/4/2014 9:35 PM, Michael Qiu wrote:
>> app/test-pmd/csumonly.c: In function ?get_psd_sum?:
>> build/include/rte_ip.h:161: error: dereferencing
Function pci_num_vf() is introduced from upstream linux-2.6.34. So
this patch make compatible with longterm kernel linux-2.6.32.63.
For RHEL, function pci_num_vf() begins from RHEL5 update9. And
it is stub-defined when CONFIG_PCI_IOV is not enabled.
So dropped the CONFIG_PCI_IOV checking of commi
The related kernel function is:
- pci_num_vf, it is introduced from upstream linux-2.6.34. For RHEL-based
kernel, it is defined from RHEL5.9.
- kstrtoul, this function is united kernel API to replace strict_strtoul in
the furture. It is introduced from linux-2.6.39. For RHEL6, it is defined
from R
Acked-by: Helin Zhang
Note: Don't forget to add the version number to your patch name next time. E.g.
[PATCH v3 0/4]
> -Original Message-
> From: Jincheng Miao [mailto:jmiao at redhat.com]
> Sent: Wednesday, December 10, 2014 11:33 AM
> To: dev at dpdk.org
> Cc: thomas.monjalon at 6wind
Hi Jincheng
I have seen your v3 patch, and ack-ed it. I just dropped my patch for the same
issue. Thank you so much!
Regards,
Helin
> -Original Message-
> From: Jincheng Miao [mailto:jmiao at redhat.com]
> Sent: Wednesday, December 10, 2014 10:55 AM
> To: Zhang, Helin; dev at dpdk.org
>
Forget to add 'v3' in header.
@helin, thanks for your review.
On 12/10/2014 11:32 AM, Jincheng Miao wrote:
> The related kernel function is:
> - pci_num_vf, it is introduced from upstream linux-2.6.34. For RHEL-based
> kernel, it is defined from RHEL5.9.
>
> - kstrtoul, this function is united ke
Thanks for your reply. Sorry, that was a typo, It was meant to be this
only.
00:04.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller
Virtual Function (rev 01)
On Wed, Dec 10, 2014 at 7:45 AM, Kiran KN wrote:
> Looks like virtual functions are not created.
> For 82599, use ixgbe
On 12/6/2014 3:01 AM, Aashima Arora wrote:
> Hi,
> I was trying to access the pci config space(BAR) of the virtual function
> device visible in the virtual machine, similar to what DPDK does on host
> via both UIO and VFIO. Did the following steps.
>
> 1. Bound PF Drivers to ixgbe and spawned virtu
Thanks for your reply.
What do you mean "device assignment" ? You mean pass-through?
> Yes, the same thing. Pass through of PCI device to VM via qemu
(pci-assign, vfio-pci, ivshmem etc)
As I knows, the answer is *NO*, because the iommu is not support in guest.
> NO was essentially what I was loo
> Though, that said, doesn't it seem to anyone else like serialization of
> enqueue
> to a port should be the responsibility of the library, not the application?
>
> Neil
>From my knowledge it is an application responsibility to serialize access to
queue on particular port.
Pawel
Hi Jincheng,
2014-12-10 11:33, Jincheng Miao:
> From upstream kernel commit 3db2e9cd, strict_strto* serial functions
> are removed. So that we should directly used kstrtoul instead.
>
> And add kni/compat.h for be compatible with older kernel.
>
> Signed-off-by: Jincheng Miao
[...]
> new file m
2014-12-10 11:33, Jincheng Miao:
> From upstream kernel commit 3db2e9cd, strict_strto* serial functions
> are removed. So that we should directly used kstrtoul instead.
>
> And add xen_dom0/compat.h for be compatible with older kernel.
>
> Signed-off-by: Jincheng Miao
Same comments as patch 3/4
- Original Message -
> Hi Jincheng,
>
> 2014-12-10 11:33, Jincheng Miao:
> > From upstream kernel commit 3db2e9cd, strict_strto* serial functions
> > are removed. So that we should directly used kstrtoul instead.
> >
> > And add kni/compat.h for be compatible with older kernel.
> >
> >
Before redefining mbuf structure, there was lack of free bits in 'ol_flags'
(32 bits in total) for new RX or TX flags. So it tried to reuse existant
bits as most as possible, or even assigning 0 to some of bit flags. After
new mbuf structure defined, there are quite a lot of free bits. So those
new
2014-12-10 03:48, Jincheng Miao:
> > It seems you forgot to include the new compat.h.
> >
> > Did you do some tests with different Fedora/RHEL versions?
>
> Yes, missing compat.h in kni_vhost.c.
>
>
> And, I want to get your opinion about adding compat.h to kni and xen_dom0.
> The pros: easy to
>
> When vfio module is not loaded when kernel support vfio feature, the
> routine still try to open the container to get file description.
>
> This action is not safe, and of cause got error messages:
>
> EAL: Detected 40 lcore(s)
> EAL: unsupported IOMMU type!
> EAL: VFIO support could not b
Hi all,
Any idea?
Leave this issue in DPDK?
Thanks,
Michael
On 12/8/2014 5:07 PM, Qiu, Michael wrote:
> Hi all,
> My platform is:
>
> uname -a
> Linux suse-11-sp3 3.0.77-0.11-xen #1 SMP Tue Mar 11 16:48:56 CST 2014
> x86_64 x86_64 x86_64 GNU/Linux
>
> gcc -v
> Using built-in specs.
> COLLECT_GCC
2014-12-10 16:55, Helin Zhang:
> Before redefining mbuf structure, there was lack of free bits in 'ol_flags'
> (32 bits in total) for new RX or TX flags. So it tried to reuse existant
> bits as most as possible, or even assigning 0 to some of bit flags. After
> new mbuf structure defined, there are
- Original Message -
> 2014-12-10 03:48, Jincheng Miao:
> > > It seems you forgot to include the new compat.h.
> > >
> > > Did you do some tests with different Fedora/RHEL versions?
> >
> > Yes, missing compat.h in kni_vhost.c.
> >
> >
> > And, I want to get your opinion about adding
> -Original Message-
> From: Doherty, Declan
> Sent: Monday, December 8, 2014 11:22 AM
> To: dev at dpdk.org
> Cc: Iremonger, Bernard; Doherty, Declan
> Subject: [PATCH] doc: add license header to link bonding diagrams
>
>
> Signed-off-by: Declan Doherty
Acked-by: Bernard Iremonger
I
On Tue, Dec 09, 2014 at 02:10:32PM -0800, Stephen Hemminger wrote:
> On Tue, 9 Dec 2014 11:45:07 -0800
> &rew wrote:
>
> > > Hey Folks,
> > >
> > > Our DPDK application deals with very large in memory data structures, and
> > > can potentially use tens or even hundreds of gigabytes of hugepage me
On Wed, Dec 10, 2014 at 10:25:41AM +0800, Michael Qiu wrote:
> When the first address is the compared address in the loop,
> it will also do memory copy, which is meaningless,
> worse more, when hugepg_tbl is mostly in order. This should
> be a big deal in large hugepage memory systerm(like hunderd
lib/librte_eal/linuxapp/eal/eal_memory.c:324:4: error: comparison
is always false due to limited range of data type [-Werror=type-limits]
|| (hugepage_sz == RTE_PGSIZE_16G)) {
^
cc1: all warnings being treated as errors
This was introuduced by commit b77b5639:
mem: add huge page si
lib/librte_eal/linuxapp/eal/eal.c(461): error #2259: non-pointer
conversion from "long long" to "void *" may lose significant bits
RTE_PTR_ALIGN_CEIL((uintptr_t)addr, RTE_PGSIZE_16M);
The root cause is that "RTE_PGSIZE_16M" is defined as unsigned long long.
But in i686 platform "void *" is 32-b
These two issues are both introuduced by commit b77b5639:
mem: add huge page sizes for IBM Power
Michael Qiu (2):
Fix compile issue with hugepage_sz in 32-bit system
Fix compile issue of eal with icc compile
lib/librte_eal/common/eal_common_memory.c | 2 +-
lib/librte_eal/common/ea
2014-12-08 09:45, Neil Horman:
> On Tue, Jul 08, 2014 at 12:16:24PM +0100, Daniel Mrzyglod wrote:
> > Signed-off-by: Daniel Mrzyglod
> Acked-by: Neil Horman
Someone to provide an explanation for commit log?
Thanks
--
Thomas
On 12/10/2014 6:41 PM, Richardson, Bruce wrote:
> On Wed, Dec 10, 2014 at 10:25:41AM +0800, Michael Qiu wrote:
>> When the first address is the compared address in the loop,
>> it will also do memory copy, which is meaningless,
>> worse more, when hugepg_tbl is mostly in order. This should
>> be a
Dear all,
In my algorithm, I am interested to perform two activities - (1)
transmitting packets to a tx_queue and (2) transmitting packets from
tx_queue to a wire - separately. I have gone through the code by putting
logs in the dpdk code and found that there is a function rte_eth_tx_burst
which
The related kernel function is:
- pci_num_vf, it is introduced from upstream linux-2.6.34. For RHEL-based
kernel, it is defined from RHEL5.9.
- kstrtoul, this function is united kernel API to replace strict_strtoul in
the furture. It is introduced from linux-2.6.39. For RHEL6, it is defined
from R
>From upstream kernel commit 3db2e9cd, strict_strto* serial functions
are removed. So that we should directly used kstrtoul instead.
Kstrtoul exists from RHEL6.4, so for compatible with old kernel and RHEL,
add some logic to igb_uio/compat.h, same as what we do for pci_num_vf().
Signed-off-by: Ji
Add kni/compat.h for be compatible with older kernel.
Signed-off-by: Jincheng Miao
---
lib/librte_eal/linuxapp/kni/compat.h| 16
lib/librte_eal/linuxapp/kni/kni_vhost.c | 3 ++-
2 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 lib/librte_eal/linuxapp/kni
And add xen_dom0/compat.h for be compatible with older kernel.
Signed-off-by: Jincheng Miao
---
lib/librte_eal/linuxapp/xen_dom0/compat.h | 16
lib/librte_eal/linuxapp/xen_dom0/dom0_mm_misc.c | 2 +-
2 files changed, 17 insertions(+), 1 deletion(-)
create mode 100644 lib
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Qiu, Michael
> Sent: Wednesday, December 10, 2014 10:59 AM
> To: Richardson, Bruce
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] Avoid possible memory cpoy when sort hugepages
>
> On 12/10/2014 6:41
On Wed, Dec 10, 2014 at 12:03:41PM +0100, Sachin Sharma wrote:
> Dear all,
>
> In my algorithm, I am interested to perform two activities - (1)
> transmitting packets to a tx_queue and (2) transmitting packets from
> tx_queue to a wire - separately. I have gone through the code by putting
> logs
Function pci_num_vf() is introduced from upstream linux-2.6.34. So
this patch make compatible with longterm kernel linux-2.6.32.63.
For RHEL, function pci_num_vf() begins from RHEL5 update9. And
it is stub-defined when CONFIG_PCI_IOV is not enabled.
So dropped the CONFIG_PCI_IOV checking of commi
On 12/10/2014 5:21 PM, Burakov, Anatoly wrote:
>> When vfio module is not loaded when kernel support vfio feature, the
>> routine still try to open the container to get file description.
>>
>> This action is not safe, and of cause got error messages:
>>
>> EAL: Detected 40 lcore(s)
>> EAL: unsupp
Hi Bruce,
In my use case, I want to have three NIC TX queues per port, and want to
fill one NIC TX queue and want to empty the other queue. Is it possible
this through tx_burst or do I need to implement these queues in
applications as you suggested before. However, in this case, I would have
then
On Wed, Dec 10, 2014 at 12:31:27PM +0100, Sachin Sharma wrote:
> Hi Bruce,
>
> In my use case, I want to have three NIC TX queues per port, and want to
> fill one NIC TX queue and want to empty the other queue. Is it possible
> this through tx_burst or do I need to implement these queues in
> appl
When vfio module is not loaded when kernel support vfio feature,
the routine still try to open the container to get file
description.
This action is not safe, and of cause got error messages:
EAL: Detected 40 lcore(s)
EAL: unsupported IOMMU type!
EAL: VFIO support could not be initialized
EAL:
> When vfio module is not loaded when kernel support vfio feature, the
> routine still try to open the container to get file description.
>
> This action is not safe, and of cause got error messages:
>
> EAL: Detected 40 lcore(s)
> EAL: unsupported IOMMU type!
> EAL: VFIO support could not be i
Hi Bruce,
>>>I'm not entirely clear on what you mean by filling one queue and
emptying another. Is this just a form of buffering you are trying to
implement?
Yes, you are right! I am implementing a buffering mechanism in which a node
will have three queues and it fills one queue with packets and
Search the right segment to increase its data length, rather than
wrongly early return and exit the tx function, which leads to drop all jumbo
frame packets
when vm2vm is in hard forward mode.
Signed-off-by: Changchun Ouyang
---
examples/vhost/main.c | 25 -
1 file chang
2014-12-10 19:04, Jincheng Miao:
> And add xen_dom0/compat.h for be compatible with older kernel.
>
> Signed-off-by: Jincheng Miao
[...]
> new file mode 100644
> index 000..89dab27
> --- /dev/null
> +++ b/lib/librte_eal/linuxapp/xen_dom0/compat.h
[...]
> --- a/lib/librte_eal/linuxapp/xen_dom0
2014-12-09 13:05, r k:
> Subject: [PATCH] Fix power_of_2 macro. Avoid branching when
> calculating RTE_MIN and RTE_MAX.
Please could you add more explanations about the problem you are solving?
You should also add a Signed-off like explained in this page:
http://dpdk.org/dev#send
Thanks
- Original Message -
> 2014-12-10 19:04, Jincheng Miao:
> > And add xen_dom0/compat.h for be compatible with older kernel.
> >
> > Signed-off-by: Jincheng Miao
> [...]
> > new file mode 100644
> > index 000..89dab27
> > --- /dev/null
> > +++ b/lib/librte_eal/linuxapp/xen_dom0/compat
And add xen_dom0/compat.h for be compatible with older kernel.
Signed-off-by: Jincheng Miao
---
lib/librte_eal/linuxapp/xen_dom0/compat.h | 16
lib/librte_eal/linuxapp/xen_dom0/dom0_mm_misc.c | 3 ++-
2 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 li
On Wed, Dec 10, 2014 at 01:09:32PM +0100, Sachin Sharma wrote:
> Hi Bruce,
>
> >>>I'm not entirely clear on what you mean by filling one queue and
> emptying another. Is this just a form of buffering you are trying to
> implement?
>
> Yes, you are right! I am implementing a buffering mechanism in
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, December 10, 2014 5:35 PM
> To: Zhang, Helin
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4] mbuf: fix of enabling all newly added RX
> error flags
>
> 2014-12-10 16:55, Helin
2014-12-05 13:46, Bruce Richardson:
> When using multiple processes, the TX function used in all processes
> should be the same, otherwise the secondary processes cannot transmit
> more than tx-ring-size - 1 packets.
> To achieve this, we extract out the code to select the ixgbe TX function
> to be
Hi Bruce,
>>>The standard sample applications with DPDK use a simple buffering
scheme, where
>>>we buffer the packets until a full burst of 32 are ready for sending.
Once we
>>>have a full burst of packets - or a timeout occurs - we then send that
burst
>>>of packets using tx_burst function. Would
On Wed, Dec 10, 2014 at 10:32:25AM +, Bruce Richardson wrote:
> On Tue, Dec 09, 2014 at 02:10:32PM -0800, Stephen Hemminger wrote:
> > On Tue, 9 Dec 2014 11:45:07 -0800
> > &rew wrote:
> >
> > > > Hey Folks,
> > > >
> > > > Our DPDK application deals with very large in memory data structures,
On Wed, Dec 10, 2014 at 09:29:26AM -0500, Neil Horman wrote:
> On Wed, Dec 10, 2014 at 10:32:25AM +, Bruce Richardson wrote:
> > On Tue, Dec 09, 2014 at 02:10:32PM -0800, Stephen Hemminger wrote:
> > > On Tue, 9 Dec 2014 11:45:07 -0800
> > > &rew wrote:
> > >
> > > > > Hey Folks,
> > > > >
>
2014-12-09 10:11, Pablo de Lara:
> Since commit b91c67e5a693211862aa7dc3b78630b4e856c2af,
> maximum number of cores is 128, which has increase
> the total memory necessary for a rte_mempool structure,
> as the per-lcore local cache has been doubled in size.
> Therefore, eal_flags unit test was brok
On Wed, Dec 10, 2014 at 08:18:36AM +, Wodkowski, PawelX wrote:
> > Though, that said, doesn't it seem to anyone else like serialization of
> > enqueue
> > to a port should be the responsibility of the library, not the application?
> >
> > Neil
>
> From my knowledge it is an application resp
On Wed, Dec 10, 2014 at 09:47:45AM -0500, Neil Horman wrote:
> On Wed, Dec 10, 2014 at 08:18:36AM +, Wodkowski, PawelX wrote:
> > > Though, that said, doesn't it seem to anyone else like serialization of
> > > enqueue
> > > to a port should be the responsibility of the library, not the
> > >
2014-12-10 13:50, Zhang, Helin:
>
> > -Original Message-
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sent: Wednesday, December 10, 2014 5:35 PM
> > To: Zhang, Helin
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v4] mbuf: fix of enabling all newly added
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Wednesday, December 10, 2014 3:55 PM
> To: Neil Horman
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Added Spinlock to l3fwd-vf example to prevent race
> conditioning
>
> On Wed, Dec
On Wed, Dec 10, 2014 at 02:54:56PM +, Bruce Richardson wrote:
> On Wed, Dec 10, 2014 at 09:47:45AM -0500, Neil Horman wrote:
> > On Wed, Dec 10, 2014 at 08:18:36AM +, Wodkowski, PawelX wrote:
> > > > Though, that said, doesn't it seem to anyone else like serialization of
> > > > enqueue
>
Subject: [PATCH] Simple fix in rte_is_power_of_2 and RTE_MIN/RTE_MAX
Number 0 is not a power_of_2, fix it in rte_is_power_of_2 function.
Avoid code which generates branching when calculating min and max.
Ravi Kerur (1):
Fix rte_is_power_of_2() function since it returns true for zero and
ze
Subject: [PATCH] Fix rte_is_power_of_2() function since it returns
true for zero and zero is not a power of 2. Avoid branching in RTE_MIN
and RTE_MAX when calculating minimum and maximum of two numbers.
Signed-off-by: Ravi Kerur
---
lib/librte_eal/common/include/rte_common.h | 6 +++---
lib/libr
Just sent another patch explaining the fix and signed-off.
Thanks,
Ravi
On Wed, Dec 10, 2014 at 4:58 AM, Thomas Monjalon
wrote:
> 2014-12-09 13:05, r k:
>> Subject: [PATCH] Fix power_of_2 macro. Avoid branching when
>> calculating RTE_MIN and RTE_MAX.
>
> Please could you add more explanations a
On Wed, Dec 10, 2014 at 5:08 AM, Ananyev, Konstantin <
konstantin.ananyev at intel.com> wrote:
> I wonder why we do need to write our own bubble sort procedure?
> Why we can't use standard qsort() here?
>
Sadly, even bubble sort would be better than the selection sort being used
here. It's guaran
> From: Jay Rolette [mailto:rolette at infiniteio.com]
> Sent: Wednesday, December 10, 2014 5:58 PM
> To: Ananyev, Konstantin
> Cc: Qiu, Michael; Richardson, Bruce; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] Avoid possible memory cpoy when sort hugepages
>
>
> On Wed, Dec 10, 2014 at 5:0
Hi Neil,
Moving __rte_cache_aligned right after struct keyword will help. On the
other hand, enforcing this rule for existing (100+) and future definitions
will be difficult. It?s clearer and a good practice to include header file
explicitly.
Thanks,
Jia
On 12/9/14, 7:22 AM, "Neil Horman" wrot
na ez :)
On Wed, 10 Dec 2014, Bruce Richardson wrote:
> On Wed, Dec 10, 2014 at 09:29:26AM -0500, Neil Horman wrote:
>> On Wed, Dec 10, 2014 at 10:32:25AM +, Bruce Richardson wrote:
>>> On Tue, Dec 09, 2014 at 02:10:32PM -0800, Stephen Hemminger wrote:
On Tue, 9 Dec 2014 11:45:07 -0800
>
On Wed, Dec 10, 2014 at 12:39 PM, Ananyev, Konstantin <
konstantin.ananyev at intel.com> wrote:
> > I just got through replacing that entire function in my repo with a call
> to qsort() from the standard library last night myself. Faster
> > (although probably not material to most deployments) and
This patch set is based on latest vhost.
It fixes vhost-user memory map/unmap alignment issue.
It uses VHOST_USER_GET_VRING_BASE as the message for vhost device stop
in vhost-user.
It uses VHOST_SET_VRING_KICK as the message that tells us vhost device
is ready in vhost-us
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, December 10, 2014 11:26 PM
> To: Zhang, Helin
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4] mbuf: fix of enabling all newly added RX
> error flags
>
> 2014-12-10 13:50, Zhan
When 'make clean' is executed, following message is thrown on console due
to missing 'comma' definition.
tr: missing operand after '.-'
Two strings must be given when translating.
Ravi Kerur (1):
When "make clean" is executed following msg is thrown
==Clean lib/librte_eal/linuxapp/kni tr: m
Subject: [PATCH] When "make clean" is executed following error msg is
thrown == Clean lib/librte_eal/linuxapp/kni tr: missing operand after '.-'
Two strings must be given when translating.
due to missing "comma" definition in Makefile.
Signed-off-by: Ravi Kerur
---
lib/librte_eal/linuxapp/kni/M
On Wed, 10 Dec 2014 11:16:46 -0500
Neil Horman wrote:
> This really seems like a false savings to me. If an application intends to
> use
> multiple processes (which by all rights it seems like the use case that the
> dpdk
> is mostly designed for) then you need locking one way or another, and
On Thu, 11 Dec 2014 00:23:24 +0100
Thomas Monjalon wrote:
> 2014-12-09 08:37, Stephen Hemminger:
> > Add missing setup for X540 MAC type when setting up VF.
> > Additional check exists in Linux driver but not in DPDK.
> >
> > Signed-off-yb: Bill Hong
> > Signed-off-by: Stephen Hemminger
> >
On Wed, Dec 10, 2014 at 07:09:03PM +, Jia Yu wrote:
> Hi Neil,
>
> Moving __rte_cache_aligned right after struct keyword will help. On the
> other hand, enforcing this rule for existing (100+) and future definitions
> will be difficult. It?s clearer and a good practice to include header file
>
On Wed, Dec 10, 2014 at 03:38:37PM -0800, Stephen Hemminger wrote:
> On Wed, 10 Dec 2014 11:16:46 -0500
> Neil Horman wrote:
>
> > This really seems like a false savings to me. If an application intends to
> > use
> > multiple processes (which by all rights it seems like the use case that the
92 matches
Mail list logo
