> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Monday, May 12, 2014 2:32 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] version: 1.7.0-rc0
>
> Start development cycle for version 1.7.0.
>
> This new development workflow intro
Hi,
I am using RSS functionality on 82599 with dpdk igb_uio driver.
I am able to get proper hash for untagged and single tagged packets. But for
double tagged packets, it is not working. I get hash value 0 for all packets.
Is there any additional flag I need to enable for this?
Regards,
Sury
Hi Stephen,
On 05/12/2014 05:59 PM, Stephen Hemminger wrote:
> There is one case which this case might make problematic.
> Right now it is possible to clone an mbuf and in the cloned mbuf
> use the associated data buffer as private meta data store.
> This is convenient (like skb->cb in Linux) and
The socket_id member of struct rte_port is an unsigned int while the d
conversion specifier of printf expects an int.
The addr_bytes member of struct ether_addr is an array of uint8_t
while the X conversion specifier of printf expects an unsigned int.
Values of type uint8_t are promoted to type in
The second condition of this logical OR:
(get_gcd(new_obj_size, nrank * nchan) != 1 ||
get_gcd(nchan, new_obj_size) != 1)
is redundant with the first condition.
We can show that the first condition is equivalent to its disjunction
with the second condition using these two results:
- R1: F
The expression (192 << 24) has an undefined behavior since:
- the integer constant 192 has type int, and
- 192 x 2^24 is not representable as an int.
Suffixing 192 with U defines a behavior since:
- the integer constant 192U has type unsigned int, and
- the value of (192U << 24) is defined as
(1
Hello all,
This patch set contains three unrelated patches found by running
TrustInSoft Analyzer [1] on some parts of the testpmd application:
- The first patch fixes a minor signed overflow in a constant
expression of testpmd.
- The second patch is not a fix and concerns a suspicious loop
c
Hi Venky,
On 05/12/2014 04:41 PM, Neil Horman wrote:
>> This is a hugely problematic change, and has a pretty large
>> performance impact (because the dependency to compute and access). We
>> debated this for a long time during the early days of DPDK and
>> decided against it. This is also a repea
2014-05-09 16:50, Olivier Matz:
> Implement TSO (TCP segmentation offload) in ixgbe driver. To delegate
> the TCP segmentation to the hardware, the user has to:
>
> - set the PKT_TX_TCP_SEG flag in mbuf->ol_flags (this flag implies
> PKT_TX_IP_CKSUM and PKT_TX_TCP_CKSUM)
> - fill the mbuf->hw_of
Hi Olivier,
2014-05-09 16:50, Olivier Matz:
> 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.
>
> Using a 16 bits unsigned integer is enough as we know that
When initializing a VF with no initial MAC address assigned by
the underlying Host PF driver, assign a default MAC address.
Signed-off-by: Ivan Boule
---
lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 54 +--
1 file changed, 46 insertions(+), 8 deletions(-)
diff --git a
The VF_RESET message of the 82599 PF/VF communication protocol issued by a
a Guest VF driver may include an optional permanent MAC address assigned to
the VF by the Guest OS, in order to make it recorded into the 82599 RAR
registers by the Host PF driver.
To indicate the absence of this optional M
On a 82599 VF, the deletion of a dynamically added MAC address consists in
first flushing all added MAC addresses, then in adding again all remaining MAC
addresses.
For this purpose, the function ixgbevf_remove_mac_addr() parses the pool
of MAC addresses associated with a VF, and must skip the VF p
During the initialization of a VF device, the rte_eth_dev_start() function
indirectly invokes the PMD "mac_addr_add" function with the permanent MAC
address assigned to the device.
In the case of 82599 VFs, this operation leads to exhausting the very
limited set of PF resources used to store VF MAC
Add missing PMD functions in the ixgbevf driver to add (respectively remove)
a MAC address to/from a 82599 VF.
For this purpose, these 2 functions use the VF/PF mailbox-based protocol.
Signed-off-by: Ivan Boule
---
lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 53 ++-
1
The first patch add 2 functions to dynamically add/remove a MAC address to/from
a ixgbe VF device.
The 2 next patches fix the behaviour of the ixgbe_vf functions used in the
first patch.
The fourth patch fix the communication framework used by the VF/PF protocol.
The last patch assigns a default MA
Olivier,
The impact isn't going to be felt on the driver quite as much (and can be
mitigated) - the driver runs a pretty low IPC (~1.7) compared to some of the
more optimized code above it that actually accesses the data. The problem with
the dependent compute is like this - in effect you are
Start development cycle for version 1.7.0.
This new development workflow introduces a new versioning scheme.
Instead of having releases r0, r1, r2, etc, there will be release
candidates. Last number has special meanings:
< 16 numbers are reserved for release candidates (RTE_VER_SUFFIX is -rc)
16 i
On Mon, May 12, 2014 at 04:06:23PM +, Venkatesan, Venky wrote:
> Olivier,
>
> The impact isn't going to be felt on the driver quite as much (and can be
> mitigated) - the driver runs a pretty low IPC (~1.7) compared to some of the
> more optimized code above it that actually accesses the da
Olivier,
This is a hugely problematic change, and has a pretty large performance impact
(because the dependency to compute and access). We debated this for a long time
during the early days of DPDK and decided against it. This is also a repeated
sequence - the driver will do it twice (Rx + Tx
Hi,
I recently picked the 1.6.0r2 from dpdk.org and tried to compile it the usual
way and ran into the following compilation error.
I am aware I can sidestep these by getting the compiler to treat them as
warnings, but these did not use to come with 1.6.0r1 so wanted to report it
here.
I am usi
Hi,
Programmer's guide section 22.1:
The hash and LPM libraries are, by design, thread unsafe in order to
maintain performance. However, if required the developer can add layers on
top of these libraries to provide thread safety. Locking is not needed in
all situations, and in both the hash and L
Hi,
Your email is invalid because of a "proprietary disclaimer".
Please stop sending such emails.
2014-05-12 14:15, Prashant Upadhyaya:
> Hi,
>
> I recently picked the 1.6.0r2 from dpdk.org and tried to compile it the
> usual way and ran into the following compilation error. I am aware I can
>
Add in and set the necessary compile-time options to enable the
vector PMD to be used in 64-bit linux.
Signed-off-by: Bruce Richardson
---
config/defconfig_x86_64-default-linuxapp-gcc |2 ++
config/defconfig_x86_64-default-linuxapp-icc |2 ++
2 files changed, 4 insertions(+), 0 deletions
New file containing optimized receive and transmit functions which
use 128bit vector instructions to improve performance. When conditions
permit, these functions will be enabled at runtime by the device
initialization routines already in the PMD.
Signed-off-by: Bruce Richardson
---
lib/librte_pm
This patch set contains the vectorized PMD implementation for the Intel DPDK.
This code was previously released under a proprietary license, but is now
being released under a BSD license to allow its integration with the rest
of the Intel DPDK codebase.
Bruce Richardson (2):
10G PMD: New vectori
On Mon, May 12, 2014 at 02:36:12PM +, Venkatesan, Venky wrote:
> Olivier,
>
> This is a hugely problematic change, and has a pretty large performance
> impact (because the dependency to compute and access). We debated this for a
> long time during the early days of DPDK and decided against
ifeq ($(CONFIG_RTE_APP_TEST),y)
SRCS-$(CONFIG_RTE_LIBRTE_ACL) += test_acl.c
diff --git a/app/test/commands.c b/app/test/commands.c
index a153026..5978cec 100644
--- a/app/test/commands.c
+++ b/app/test/commands.c
@@ -178,6 +178,8 @@ static void cmd_autotest_parsed(void *parsed_result,
Add in and set the necessary compile-time options to enable the
vector PMD to be used in 64-bit linux.
Signed-off-by: Bruce Richardson
---
config/defconfig_x86_64-default-linuxapp-gcc |2 ++
config/defconfig_x86_64-default-linuxapp-icc |2 ++
2 files changed, 4 insertions(+), 0 deletions
New file containing optimized receive and transmit functions which
use 128bit vector instructions to improve performance. When conditions
permit, these functions will be enabled at runtime by the device
initialization routines already in the PMD.
Signed-off-by: Bruce Richardson
---
lib/librte_pm
This patch set contains the vectorized PMD implementation for the Intel DPDK.
This code was previously released under a proprietary license, but is now
being released under a BSD license to allow its integration with the rest
of the Intel DPDK codebase.
Bruce Richardson (2):
10G PMD: New vectori
On Mon, 12 May 2014 18:13:26 +0200
Olivier MATZ wrote:
> Hi Stephen,
>
> On 05/12/2014 05:59 PM, Stephen Hemminger wrote:
> > There is one case which this case might make problematic.
> > Right now it is possible to clone an mbuf and in the cloned mbuf
> > use the associated data buffer as priva
Please ignore, my patch seems to have got corrupted with some other WIP content
that will be upstreamed in a future patch set.
/Bruce
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Monday, May 12, 2014 10:23 AM
> To: dev at dpdk.or
On Mon, 12 May 2014 17:07:03 +0200
Olivier MATZ wrote:
> Hi Venky,
>
> On 05/12/2014 04:41 PM, Neil Horman wrote:
> >> This is a hugely problematic change, and has a pretty large
> >> performance impact (because the dependency to compute and access). We
> >> debated this for a long time during t
Hello all!
I have a question regarding the possible concurrency issues in hash table. My
questions is:
Is it possible to call rte_hash_add() and rte_hash_lookup() at the same time
without data inconsistency?
My guess is that I need to use a lock as protection. I see that you have a
couple of
On Mon, May 12, 2014 at 11:11:56AM +0200, Thomas Monjalon wrote:
> Hi,
>
> Your email is invalid because of a "proprietary disclaimer".
>
> Please stop sending such emails.
>
>
Except that this totally happens if you set RHEL_RELEASE_CODE to somthing larger
than (6,4). ethtool_adv_to_mmd_eee_a
36 matches
Mail list logo
