We have got some feedback about backward compatibility of VXLAN TX checksum
offload API with 1G/10G NIC after the i40e VXLAN TX checksum codes were
applied, so we have to rework the APIs on i40e, including the changes of mbuf,
i40e PMD and csum engine.
The main changes in mbuf are as follows,
I
Rework the i40e PMD codes using the new introduced ol_flags and fields.
Signed-off-by: Jijiang Liu
---
lib/librte_pmd_i40e/i40e_rxtx.c | 49 +-
1 files changed, 27 insertions(+), 22 deletions(-)
diff --git a/lib/librte_pmd_i40e/i40e_rxtx.c b/lib/librte_pm
In place of removing the PKT_TX_VXLAN_CKSUM, we introduce 3 new flags:
PKT_TX_OUTER_IP_CKSUM, PKT_TX_OUTER_IPV6 and PKT_TX_UDP_TUNNEL_PKT, and a new
field: l4_tun_len.
Replace the inner_l2_len and the inner_l3_len field with the outer_l2_len and
outer_l3_len field.
PKT_TX_OUTER_IP_CKSUM: is not
It will avoid to send a packet with a bad info:
- we receive a Ether/IP6/IP4/L4/data packet
- the driver sets PKT_RX_IPV6_HDR
- the stack decapsulates IP6
- the stack sends the packet, it has the PKT_TX_IPV6 flag but it's an IPv4
packet.
Signed-off-by: Jijiang Liu
---
lib/librte_mbuf/rt
The changes include:
1. use the new introduced ol_flags and fields in csumonly.c file;
2. fix an issue of outer UDP checksum check;
3. change process logic in the process_inner_cksums();
Signed-off-by: Jijiang Liu
---
app/test-pmd/csumonly.c | 65 ++
We have got some feedback about backward compatibility of VXLAN TX checksum
offload API with 1G/10G NIC after the i40e VXLAN TX checksum codes were
applied, so we have to rework the APIs on i40e, including the changes of mbuf,
i40e PMD and csum engine.
The main changes in mbuf are as follows,
I
In place of removing the PKT_TX_VXLAN_CKSUM, we introduce 3 new flags:
PKT_TX_OUTER_IP_CKSUM, PKT_TX_OUTER_IPV6 and PKT_TX_UDP_TUNNEL_PKT, and a new
field: l4_tun_len.
Replace the inner_l2_len and the inner_l3_len field with the outer_l2_len and
outer_l3_len field.
PKT_TX_OUTER_IP_CKSUM: is not
It will avoid to send a packet with a bad info:
- we receive a Ether/IP6/IP4/L4/data packet
- the driver sets PKT_RX_IPV6_HDR
- the stack decapsulates IP6
- the stack sends the packet, it has the PKT_TX_IPV6 flag but it's an IPv4
packet.
Signed-off-by: Jijiang Liu
---
lib/librte_mbuf/rt
Rework the i40e PMD codes using the new introduced ol_flags and fields.
Signed-off-by: Jijiang Liu
---
lib/librte_pmd_i40e/i40e_rxtx.c | 52 +--
1 files changed, 28 insertions(+), 24 deletions(-)
diff --git a/lib/librte_pmd_i40e/i40e_rxtx.c b/lib/librte_pmd
The changes include:
1. use the new introduced ol_flags and fields in csumonly.c file;
2. fix an issue of outer UDP checksum check;
3. change process logic in the process_inner_cksums();
Signed-off-by: Jijiang Liu
---
app/test-pmd/csumonly.c | 65 ++
Hi Thomas
New version is needed for i40e flow control.
Regards,
Helin
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Thursday, November 27, 2014 11:51 PM
> To: Zang, Zhida
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] i
Hi all,
I have no comments on this issue, but I indeed see many places do have
this kernel issue(before/now/future), so can solve this issue globally?
Thus, we do not need to fix this case by case.
One solution(not sure if it works or not):
1. features and kernel version required list.
2. When
On 28/11/14 1:54 am, "Thomas Monjalon" wrote:
>2014-11-27 19:01, Thomas Monjalon:
>> 2014-11-27 22:44, Sujith Sankar:
>> > Inclusion of vfio.h was giving compilation errors if kernel version
>>is less
>> > than 3.6.0 and if RTE_EAL_VFIO was on in config.
>> >
>> > Replaced inclusion of vfio.h
28.11.2014 3:04, Thomas Monjalon ?:
> 2014-11-20 11:15, Yerden Zhumabekov:
>> These patches bring a fallback mechanism to ensure that CRC32 hash is
>> calculated regardless of hardware support from CPU (i.e. SSE4.2 intrinsics).
>> Performance is also improved by slicing data in 8 bytes.
>>
>>
ENIC PMD was giving compilation errors on ppc_64-power8-linuxapp-gcc because
of types such as u_int32_t. This patch replaces all those with uint32_t and
similar ones.
Reported-by: David Marchand
Signed-off-by: Sujith Sankar
---
lib/librte_pmd_enic/enic.h | 2 +-
lib/librte_pmd_e
Hi Olivier, Konstantin
> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Wednesday, November 26, 2014 10:12 PM
> To: Ananyev, Konstantin; Zhang, Helin; dev at dpdk.org
> Cc: Cao, Waterman; Cao, Min
> Subject: Re: [PATCH] i40e: Use one bit flag for all har
On 11/28/2014 01:01 AM, Thomas Monjalon wrote:
> 2014-10-31 15:37, Jincheng Miao:
>> 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 RHEL6's kernel, although it is based on linux-2.6.32, it has
>> pci_
Hi Helin,
On 11/28/2014 09:07 AM, Zhang, Helin wrote:
> After I have completed another task, I read the datasheet carefully again.
> For those 5
> error bits I introduced for a long time, I'd like to explain one by one as
> below.
>
> #define PKT_RX_EIP_CKSUM_BAD (0ULL << 0) /**< External IP h
Hello Sujith,
Why keep those u8, u16, u32 etc... ?
Especially, you can see in this patch that the ioread16 uses u16, while
ioread8, ioread32 uses uint*.
I like consistency and "standard" types (unless there is a reason why we
use different types).
Anyway, this patch builds fine on ppc.
--
David
Tested-by: Min Cao
Patch name: [dpdk-dev] [PATCH v2] ixgbe: fix icc issue with mbuf
initializer
Test Flag: Tested-by
Tester name:min.cao at intel.com
ICC version:13.1.2
ICC package:l_ccompxe_2013.4.183.tgz
Result summary:
Tested-by: Min Cao
Patch name: [dpdk-dev] [PATCH v2] ixgbe: fix icc issue with mbuf
initializer
Test Flag: Tested-by
Tester name:min.cao at intel.com
ICC version:13.1.2
ICC package:l_ccompxe_2013.4.183.tgz
Result summary:
Hi Olivier,
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Thursday, November 27, 2014 7:02 PM
> To: Olivier MATZ; dev at dpdk.org
> Cc: Walukiewicz, Miroslaw; Liu, Jijiang; Liu, Yong; jigsaw at gmail.com;
> Richardson,
> Bruce
> Subject: RE: [PATCH v4 08/13] testpmd: rework csu
Hi Jijiang,
On 11/27/2014 02:14 PM, Liu, Jijiang wrote:
>>> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
>>> index 367fc56..48cd8e1 100644
>>> --- a/lib/librte_mbuf/rte_mbuf.h
>>> +++ b/lib/librte_mbuf/rte_mbuf.h
>>> @@ -99,10 +99,9 @@ extern "C" {
>>> #define PKT_RX_TUN
The statistics that is reported through the rx_nombuf fields in struct
rte_eth_stats was not set when the vector PMD was used. The statistics
should report the number of mbufs that could _not_ be allocated during
rearm of the RX queue. The non-vector PMD reports it correctly. The
use of either vect
Hi David,
The u8, u16, etc are there because enicpmd shares a lot of code with kernel
mode driver and these are used at a lot of places.
I agree with you on bringing in consistency. Let me change ioread16 with
uint16 and upload a new patch.
Hope this is ok with you.
Thanks,
-Sujith
From: Dav
Hi Konstantin,
On 11/27/2014 04:29 PM, Ananyev, Konstantin wrote:
>> As I suggested in the TSO thread, I think the following semantics
>> is easier to understand for the user:
>>
>>- PKT_TX_IP_CKSUM: tell the NIC to compute IP cksum
>>
>>- PKT_TX_IPV4: tell the NIC it's an IPv4 packet. Req
Hi Jijiang,
On 11/27/2014 06:03 PM, Jijiang Liu wrote:
> /** Tell the NIC it's an IPv4 packet. Required for L4 checksum offload or
> TSO. */
> #define PKT_TX_IPV4 PKT_RX_IPV4_HDR
>
> /** Tell the NIC it's an IPv6 packet. Required for L4 checksum offload or
> TSO. */
> #define PKT_
On 11/27/2014 06:03 PM, Jijiang Liu wrote:
> It will avoid to send a packet with a bad info:
> - we receive a Ether/IP6/IP4/L4/data packet
> - the driver sets PKT_RX_IPV6_HDR
> - the stack decapsulates IP6
> - the stack sends the packet, it has the PKT_TX_IPV6 flag but it's an IPv4
> pac
ENIC PMD was giving compilation errors on ppc_64-power8-linuxapp-gcc because
of types such as u_int32_t. This patch replaces all those with uint32_t and
similar ones.
Reported-by: David Marchand
Signed-off-by: Sujith Sankar
---
lib/librte_pmd_enic/enic.h | 2 +-
lib/librte_pmd_eni
Hi Jijiang,
On 11/27/2014 06:03 PM, Jijiang Liu wrote:
> @@ -303,7 +305,7 @@ process_outer_cksums(void *outer_l3_hdr, uint16_t
> outer_ethertype,
> * TESTPMD_TX_OFFLOAD_* in ports[tx_port].tx_ol_flags. They control
> * wether a checksum must be calculated in software or in hardware. The
> *
Hi Jijiang,
On 11/28/2014 09:54 AM, Liu, Jijiang wrote:
>>> My understanding of the meaning of the flags is:
>>>
>>>- PKT_TX_IP_CKSUM: tell the NIC to compute IP cksum
>
>> My initial thought:
>> It tells the NIC that it is an IPV4 packet for which it has to compute
>> checksum.
>>
>>>
>>>
2014-11-28 10:50, Olivier MATZ:
> Hi Jijiang,
>
> On 11/27/2014 06:03 PM, Jijiang Liu wrote:
> > @@ -303,7 +305,7 @@ process_outer_cksums(void *outer_l3_hdr, uint16_t
> > outer_ethertype,
> > * TESTPMD_TX_OFFLOAD_* in ports[tx_port].tx_ol_flags. They control
> > * wether a checksum must be ca
Hi Sujith,
Some tips when sending a v2:
- use --in-reply-to to keep all the versions in the same thread
- use --annotate to write a changelog
These guidelines are explained in this page:
http://dpdk.org/dev#send
Thanks
--
Thomas
Sure Thomas. Thanks !
Do you want me to send this V2 again with these?
-Sujith
On 28/11/14 3:47 pm, "Thomas Monjalon" wrote:
>Hi Sujith,
>
>Some tips when sending a v2:
>- use --in-reply-to to keep all the versions in the same thread
>- use --annotate to write a changelog
>
>These guidelines a
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier MATZ
> Sent: Friday, November 28, 2014 9:37 AM
> To: Liu, Jijiang; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 1/4] mbuf:add three TX offload flags and
> change three fields
>
> Hi Jijiang,
>
2014-11-28 10:21, Sujith Sankar:
> Sure Thomas. Thanks !
> Do you want me to send this V2 again with these?
No, not needed. Just a reminder for next time in the hope you'll
send hundreds of good patches ;)
Note: avoid top-posting (there's also some guidelines for emails).
> On 28/11/14 3:47 pm,
Hi Olivier,
> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Friday, November 28, 2014 5:37 PM
> To: Liu, Jijiang; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 1/4] mbuf:add three TX offload flags and
> change three fields
>
> Hi Jijiang,
>
> On
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Liu, Jijiang
> Sent: Friday, November 28, 2014 10:33 AM
> To: Olivier MATZ; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 1/4] mbuf:add three TX offload flags and
> change three fields
>
> Hi Olivier,
>
Hi Konstantin,
On 11/27/2014 06:01 PM, Ananyev, Konstantin wrote:
>> Yes, I think it could be done that way too.
>> Though I still prefer to keep l4tun_len - it makes things a bit cleaner (at
>> least to me).
>> After all we do have space for it in mbuf's tx_offload.
>
> As one more thing in fa
Hi Konstantin,
On 11/28/2014 11:40 AM, Ananyev, Konstantin wrote:
>
> Well, I still prefer them to be mutually exclusive.
> Even better, if we can squeeze these 3 flags into 2 bits.
> Would save us 2 bits, plus might be handy, as in the PMD you can do:
>
> switch (ol_flags & TX_L3_MASK) {
>
> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Friday, November 28, 2014 11:00 AM
> To: Ananyev, Konstantin; Liu, Jijiang; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 1/4] mbuf:add three TX offload flags and
> change three fields
>
> Hi Kon
Hi Olver,
> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Friday, November 28, 2014 10:46 AM
> To: Ananyev, Konstantin; Liu, Jijiang
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/3] mbuf:add two TX offload flags and change
> three fields
>
Hi Konstantin,
On 11/28/2014 12:13 PM, Ananyev, Konstantin wrote:
>>> For the upper layer, I think there would be no big difference, what ways we
>>> will choose.
>>
>> I think the 2 informations are transversal, and that's why I would
>> prefer 2 flags. Also, having 2 separate flags would also h
On Thu, Nov 27, 2014 at 12:29:05PM +0100, David Marchand wrote:
> When redefining the same symbol in configuration (basically after an
> inclusion),
> we need to undefine the previous symbol to avoid "redefined" errors.
>
> Signed-off-by: David Marchand
Though I see this patch is already replie
These patches mainly support configuring hash functions. In detail,
- It can get/set global hash configurations.
* Get/set symmetric hash enable per flow type.
* Get/set hash function type.
- It can get/set symmetric hash enable per port.
- Four commands have been implemented in testpmd to s
Added code style fixes.
Signed-off-by: Helin Zhang
---
lib/librte_ether/rte_eth_ctrl.h | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index 7088d8d..6ab16c2 100644
--- a/lib/librte_ether/rte_eth_ctrl.
To demonstrate the hash filter control, commands are added.
They are,
- get_sym_hash_ena_per_port
- set_sym_hash_ena_per_port
- get_hash_global_config
- set_hash_global_config
Signed-off-by: Helin Zhang
---
app/test-pmd/cmdline.c | 334 +
1 file ch
Calculating the default RSS hash keys at run time is not needed
at all, and may have race conditions. The alternative is to use
array of random values which were generated manually as the
default hash keys.
Signed-off-by: Helin Zhang
---
lib/librte_pmd_i40e/i40e_ethdev.c | 14 +++---
1 f
Hash filter control has been implemented for i40e. It includes
getting/setting,
- global hash configurations (hash function type, and symmetric
hash enable per flow type)
- symmetric hash enable per port
Signed-off-by: Helin Zhang
---
lib/librte_ether/rte_eth_ctrl.h | 63
lib/librt
Hi Helin,
Few nits from me.
Konstantin
> -Original Message-
> From: Zhang, Helin
> Sent: Friday, November 28, 2014 12:14 PM
> To: dev at dpdk.org
> Cc: Cao, Waterman; Cao, Min; Ananyev, Konstantin; Zhang, Helin
> Subject: [PATCH v7 3/4] i40e: support of controlling hash functions
>
> Has
On Fri, Nov 28, 2014 at 09:21:45AM +, Balazs Nemeth wrote:
> The statistics that is reported through the rx_nombuf fields in struct
> rte_eth_stats was not set when the vector PMD was used. The statistics
> should report the number of mbufs that could _not_ be allocated during
> rearm of the RX
On Fri, Nov 28, 2014 at 03:08:19PM +0530, Sujith Sankar wrote:
> ENIC PMD was giving compilation errors on ppc_64-power8-linuxapp-gcc because
> of types such as u_int32_t. This patch replaces all those with uint32_t and
> similar ones.
>
> Reported-by: David Marchand
> Signed-off-by: Sujith Sank
On Thu, Nov 27, 2014 at 10:17:22AM -0800, Thomas Monjalon wrote:
> > When redefining the same symbol in configuration (basically after an
> > inclusion),
> > we need to undefine the previous symbol to avoid "redefined" errors.
> >
> > Signed-off-by: David Marchand
>
> Acked-by: Thomas Monjalon
Hello Bruce,
On Fri, Nov 28, 2014 at 2:56 PM, Bruce Richardson <
bruce.richardson at intel.com> wrote:
> On Thu, Nov 27, 2014 at 10:17:22AM -0800, Thomas Monjalon wrote:
> > > When redefining the same symbol in configuration (basically after an
> inclusion),
> > > we need to undefine the previous
2014-11-28 02:09, Qiu, Michael:
> I have no comments on this issue, but I indeed see many places do have
> this kernel issue(before/now/future), so can solve this issue globally?
>
> Thus, we do not need to fix this case by case.
>
> One solution(not sure if it works or not):
>
> 1. features and
Since commit 0a91453d, "Fix symbol overriding in configuration", the
rte_config.h can have two lines generated for a single directive to
enable a feature - one line to undef the feature value, and a second
to enable or set the new value. On FreeBSD, sed inserts an "n" char
instead of the "\n" carri
On Fri, Nov 28, 2014 at 03:06:11PM +0100, David Marchand wrote:
> Hello Bruce,
>
> On Fri, Nov 28, 2014 at 2:56 PM, Bruce Richardson <
> bruce.richardson at intel.com> wrote:
>
> > On Thu, Nov 27, 2014 at 10:17:22AM -0800, Thomas Monjalon wrote:
> > > > When redefining the same symbol in configur
On Fri, Nov 28, 2014 at 03:06:11PM +0100, David Marchand wrote:
> Hello Bruce,
>
> On Fri, Nov 28, 2014 at 2:56 PM, Bruce Richardson <
> bruce.richardson at intel.com> wrote:
>
> > On Thu, Nov 27, 2014 at 10:17:22AM -0800, Thomas Monjalon wrote:
> > > > When redefining the same symbol in configur
On Fri, Nov 28, 2014 at 3:43 PM, Bruce Richardson <
bruce.richardson at intel.com> wrote:
> This proposed fix also works. I don't mind whether my patch proposal or
> this
> fix gets applied - gen-config-h.sh is not a commonly modified script
> anyway.
>
I prefer my ugliness ;-)
But Thomas just pr
On Fri, Nov 28, 2014 at 02:09:40AM +, Qiu, Michael wrote:
> Hi all,
>
> I have no comments on this issue, but I indeed see many places do have
> this kernel issue(before/now/future), so can solve this issue globally?
>
> Thus, we do not need to fix this case by case.
>
> One solution(not sur
On Fri, Nov 28, 2014 at 03:49:29PM +0100, David Marchand wrote:
> On Fri, Nov 28, 2014 at 3:43 PM, Bruce Richardson <
> bruce.richardson at intel.com> wrote:
>
> > This proposed fix also works. I don't mind whether my patch proposal or
> > this
> > fix gets applied - gen-config-h.sh is not a commo
gcc 4.3 complains that slow_pkts array in bond_ethdev_tx_burst_8023ad may be
used uninitialized, so it has been initialized to NULL
Signed-off-by: Pablo de Lara
---
lib/librte_pmd_bond/rte_eth_bond_pmd.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/librte_pmd_bo
2014-11-28 15:10, Pablo de Lara:
> gcc 4.3 complains that slow_pkts array in bond_ethdev_tx_burst_8023ad may be
> used uninitialized, so it has been initialized to NULL
>
> Signed-off-by: Pablo de Lara
Acked-by: Thomas Monjalon
Applied
Thanks
--
Thomas
> > The statistics that is reported through the rx_nombuf fields in struct
> > rte_eth_stats was not set when the vector PMD was used. The statistics
> > should report the number of mbufs that could _not_ be allocated during
> > rearm of the RX queue. The non-vector PMD reports it correctly. The
>
When compiling with clang, errors were being emitted due to truncation
of values when assigning to the tx_offload_mask bit fields.
dpdk.org/lib/librte_pmd_ixgbe/ixgbe_rxtx.c:404:27: fatal error: implicit
truncation from 'int' to bitfield changes value from -1 to 127
[-Wbitfield-constant-conversi
Hi Sergio, Neil,
Do you agree to add this comment (before applying this *needed* patch)?
+# Workaround lack of DT_NEEDED entry
> -EXECENV_LDFLAGS =
> +EXECENV_LDFLAGS = --no-as-needed
--
Thomas
On Fri, Nov 28, 2014 at 3:59 PM, Bruce Richardson <
bruce.richardson at intel.com> wrote:
> Yes, it's ugly, but it's probably more resilient. I'm looking forward to
> getting
> an option C.
>
Option C and D are ugly as well (using some bashism like $' ' or using an
intermediate variable with a ne
Use of \n in sed expression is not portable and triggered an invalid
configuration on BSD (at least).
Replace with an explicit newline.
Reported-by: Bruce Richardson
Signed-off-by: David Marchand
---
scripts/gen-config-h.sh |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --
> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Friday, November 28, 2014 11:19 AM
> To: Ananyev, Konstantin; Liu, Jijiang; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 1/4] mbuf:add three TX offload flags and
> change three fields
>
> Hi Kons
Hi Sergio,
2014-10-22 17:36, Sergio Gonzalez Monroy:
> Incompatible libraries error when building shared libraries for 32bits on
> a 64bits system.
> Fix issue by passing CPU_CFLAGS to CC when LINK_USING_CC is enabled.
This issue looks really strange. If that's the only way to fix it,
it would be
On Fri, Nov 28, 2014 at 04:42:44PM +0100, David Marchand wrote:
> Use of \n in sed expression is not portable and triggered an invalid
> configuration on BSD (at least).
> Replace with an explicit newline.
>
> Reported-by: Bruce Richardson
> Signed-off-by: David Marchand
Acked-by: Bruce Richard
On Fri, Nov 28, 2014 at 10:38 AM, Sujith Sankar wrote:
> ENIC PMD was giving compilation errors on ppc_64-power8-linuxapp-gcc
> because
> of types such as u_int32_t. This patch replaces all those with uint32_t
> and
> similar ones.
>
> Reported-by: David Marchand
> Signed-off-by: Sujith Sankar
On Fri, Nov 28, 2014 at 03:08:19PM +0530, Sujith Sankar wrote:
> ENIC PMD was giving compilation errors on ppc_64-power8-linuxapp-gcc because
> of types such as u_int32_t. This patch replaces all those with uint32_t and
> similar ones.
>
> Reported-by: David Marchand
> Signed-off-by: Sujith Sank
2014-10-23 16:36, Sergio Gonzalez Monroy:
> Building combined shared libraries results in applications being linked
> against separeted/individual and combined libs altogether.
>
> Link only against combined lib when the config option is enabled.
>
> Signed-off-by: Sergio Gonzalez Monroy
[...]
>
> > ENIC PMD was giving compilation errors on ppc_64-power8-linuxapp-gcc because
> > of types such as u_int32_t. This patch replaces all those with uint32_t and
> > similar ones.
> >
> > Reported-by: David Marchand
> > Signed-off-by: Sujith Sankar
>
> Acked-by: Bruce Richardson
>
> This patc
On 28/11/14 9:22 pm, "Bruce Richardson" wrote:
>On Fri, Nov 28, 2014 at 03:08:19PM +0530, Sujith Sankar wrote:
>> ENIC PMD was giving compilation errors on ppc_64-power8-linuxapp-gcc
>>because
>> of types such as u_int32_t. This patch replaces all those with
>>uint32_t and
>> similar ones.
>>
> > Use of \n in sed expression is not portable and triggered an invalid
> > configuration on BSD (at least).
> > Replace with an explicit newline.
> >
> > Reported-by: Bruce Richardson
> > Signed-off-by: David Marchand
>
> Acked-by: Bruce Richardson
Applied
Thanks
--
Thomas
On Fri, Nov 28, 2014 at 04:01:00PM +, Sujith Sankar (ssujith) wrote:
>
>
> On 28/11/14 9:22 pm, "Bruce Richardson" wrote:
>
> >On Fri, Nov 28, 2014 at 03:08:19PM +0530, Sujith Sankar wrote:
> >> ENIC PMD was giving compilation errors on ppc_64-power8-linuxapp-gcc
> >>because
> >> of types s
On 28/11/14 9:36 pm, "Bruce Richardson" wrote:
>On Fri, Nov 28, 2014 at 04:01:00PM +, Sujith Sankar (ssujith) wrote:
>>
>>
>> On 28/11/14 9:22 pm, "Bruce Richardson"
>>wrote:
>>
>> >On Fri, Nov 28, 2014 at 03:08:19PM +0530, Sujith Sankar wrote:
>> >> ENIC PMD was giving compilation erro
2014-11-28 16:13, Jincheng Miao:
>
> On 11/28/2014 01:01 AM, Thomas Monjalon wrote:
> > 2014-10-31 15:37, Jincheng Miao:
> >> 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 RHEL6's kernel, altho
2014-10-31 15:37, Jincheng Miao:
> From upstream kernel commit 3db2e9cd, strict_strto* serial functions
> are removed. So that we should directly used kstrtoul instead.
>
> For compatible with old kernel and RHEL6, add some logic to
> igb_uio/compat.h, same as what we do for pci_num_vf().
>
> Sig
This patch adds a new sample app UG, contaning explanation
of the new two sample apps added in the VM power management
patchset
Changes in v2:
Corrected svg files
Signed-off-by: Pablo de Lara
---
.../sample_app_ug/img/vm_power_mgr_highlevel.svg | 1173
.../img/vm_power_m
Hello,
I have ~15Gbps of traffic flowing through two 10GE ports and been profiling
the rte mempool(or rather the pktmbuf mempool) memory consumption:
I have per lcore caching disabled(cache_size is 0)
I have noticed that:
- Mempool FREE cnt(as given byt rte_mempool_free_count()) increases
- Memp
83 matches
Mail list logo
