Hi Wei,
Have you had a chance to look at the debug output yet? Is there any
additional data you need?
Regards,
Roger
On 5/24/17 2:38 PM, Roger B. Melton wrote:
Hi Wei,
I am using ixgbe:
00:02.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit
SFI/SFP+ Network Connection (rev
On 4/24/17 11:49 AM, Mcnamara, John wrote:
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
Sent: Monday, April 24, 2017 1:41 PM
To: Kozak, KubaX
Cc: dev@dpdk.org; Olivier Matz ; Van Haaren, Harry
; Jain, Deepak K ;
Piasecki, JacekX
Subject: Re: [d
t's the
proper fix?
Regards,
Roger
--
________
|Roger B. Melton| | Cisco Systems |
|CPP Software :|::|: 7100 Kit Creek Rd |
|+1.919.476.2332 phone:|||: :|||:RTP, NC 27709-4987 |
|+1.919.392.
Thanks -Roger
On 5/10/17 4:20 AM, Dai, Wei wrote:
Yes, it is a bug.
The hw->mac.ops.get_media_type of ixgbe VF is NULL.
I have just submitted a patch to fix it.
http://dpdk.org/dev/patchwork/patch/24188/
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Roge
On 5/10/17 5:50 AM, Ferruh Yigit wrote:
On 5/10/2017 8:00 AM, Wei Dai wrote:
hw->mac.ops.get_media-type() of ixgbe VF is NULL and should not
be called directly. It had better be replaced by calling
ixgbe_get_media_type( ) to avoid crash.
Fixes: c12d22f65b13 ("net/ixgbe: ensure link status is
:
hw->mac.ops.get_media-type() of ixgbe VF is NULL and should not
be called directly. It had better be replaced by calling
ixgbe_get_media_type( ) to avoid crash.
Fixes: c12d22f65b13 ("net/ixgbe: ensure link status is updated")
Cc: sta...@dpdk.org
Signed-off-by: Wei Dai
Tested-by R
Hi Laurent/Wei,
As I continue to integrate DPDK 17.05 into my application, I have hit
another issue with this patch while testing in a VM with multispeed
fiber ixgbe PCI passthrough. My application periodically invokes
rte_eth_link_get_nowait() to detect link state changes. If the link is
d
Hi Laurent/Wei,
Any thoughts?
Regards,
Roger
On 5/17/17 9:31 AM, Roger B Melton wrote:
Hi Laurent/Wei,
As I continue to integrate DPDK 17.05 into my application, I have hit
another issue with this patch while testing in a VM with multispeed
fiber ixgbe PCI passthrough. My application
hould set --log-level=8
Regards
-Wei
-Original Message-
From: Dai, Wei
Sent: Tuesday, May 23, 2017 3:24 PM
To: 'Roger B. Melton' ; Laurent Hardy
; dev@dpdk.org
Cc: Yigit, Ferruh ; Zhang, Helin
; Ananyev, Konstantin
; olivier.m...@6wind.com
Subject: RE: 2nd try: problem with ix
18:15:39.887 (debug): PMD: ixgbe_check_mac_link_generic():
ixgbe_check_mac_link_generic
2017/05/24 18:15:39.887 (debug): rmeltonDBG
posix_pmd_oper_state_get_by_id:End rte_eth_link_get_nowait()
On 5/24/17 10:40 AM, Roger B. Melton wrote:
Hi Wei,
Thanks for getting back to me. I'm
On 4/17/18 4:46 PM, Stephen Hemminger wrote:
On Tue, 17 Apr 2018 13:01:14 -0700
Jim Murphy wrote:
Still used in certain memory constrained environments.
On Tue, Apr 17, 2018 at 11:39 AM, David Harton (dharton)
wrote:
It is used and tested in production and non-production environments.
Re
Hi folks,
Resurrecting this old thread. I ran across this issue recently in DPDK
17.05, and it's also present in17.08. It appears no fix was committed.
I'm working on a solution, but if anyone has a fix in flight please let
me know.
Regards,
Roger
On 4/29/16 3:29 AM, Olivier Matz wrote:
---
i40evf tx vector logic frees mbufs, but it does not remove the
mbufs from software rings which leads to double frees. This change
corrects that oversight. We've validated this fix within our application.
drivers/net/i40e/i40e_rxtx_vec_common.h | 4
1 file changed, 4 insertions(+)
di
Hi Everyone,
As soon as I submitted the patch, I realized I neglected to signoff.
What's the recommended procedure, resubmit the original signed off, or
bump to v1?
Thanks,
Roger
On 10/5/17 3:11 PM, Roger B Melton wrote:
---
i40evf tx vector logic frees mbufs, but it does not remov
On 10/6/17 4:54 AM, Bruce Richardson wrote:
On Thu, Oct 05, 2017 at 03:11:11PM -0400, Roger B Melton wrote:
---
i40evf tx vector logic frees mbufs, but it does not remove the
mbufs from software rings which leads to double frees. This change
corrects that oversight. We've validated
On 10/6/17 9:51 AM, Bruce Richardson wrote:
On Fri, Oct 06, 2017 at 08:38:01AM -0400, Roger B. Melton wrote:
On 10/6/17 4:54 AM, Bruce Richardson wrote:
On Thu, Oct 05, 2017 at 03:11:11PM -0400, Roger B Melton wrote:
---
i40evf tx vector logic frees mbufs, but it does not remove the
mbufs
Signed-off-by: Roger B Melton
---
v2 - Same content as v1, but properly signed-off.
i40evf tx vector logic frees mbufs, but it does not remove the
mbufs from software rings which leads to double frees. This change
corrects that oversight. I've validated this fix within our applic
loopback packets are big endian.
For i350 VLAN loopback packets, swap the tag when copying from the
RX descriptor to the mbuf header. This will ensure that the mbuf
vlan_tci is always little endian.
Signed-off-by: Roger B Melton
---
drivers/net/e1000/igb_rxtx.c | 56
Hi Bruce,
I can. It will take a day or 2 to get the results.
Regards,
Roger
On 10/10/17 4:48 AM, Bruce Richardson wrote:
+Roger Melton
On Tue, Oct 10, 2017 at 09:22:05AM -0400, Qi Zhang wrote:
vPMD tx does not set sw_ring's mbuf to NULL after free it.
So to prevent same mbuf be free again,
On 10/10/17 7:39 AM, Bruce Richardson wrote:
On Tue, Oct 10, 2017 at 07:05:33AM -0400, Roger B. Melton wrote:
Hi Bruce,
I can. It will take a day or 2 to get the results.
Regards,
Roger
Thanks. Keep us posted. We want to ensure we have the best fix possible
for the issue in this release
Hi Wenzhou,
On 10/10/17 9:32 PM, Lu, Wenzhuo wrote:
Hi Roger,
-Original Message-
From: Roger B Melton [mailto:rmel...@cisco.com]
Sent: Saturday, October 7, 2017 7:34 AM
To: Lu, Wenzhuo
Cc: dev@dpdk.org; Roger B Melton
Subject: [PATCH] net/e1000: i350 VLAN tags in loopback packets
On 10/10/17 7:47 AM, Roger B. Melton wrote:
On 10/10/17 7:39 AM, Bruce Richardson wrote:
On Tue, Oct 10, 2017 at 07:05:33AM -0400, Roger B. Melton wrote:
Hi Bruce,
I can. It will take a day or 2 to get the results.
Regards,
Roger
Thanks. Keep us posted. We want to ensure we have the best
tags in loopback packets for
those devices are big endian.
For i350, i354 and i350vf VLAN loopback packets, swap the tag when
copying from the RX descriptor to the mbuf header. This will ensure
that the mbuf vlan_tci is always little endian.
Signed-off-by: Roger B Melton
---
v2:
* PF: Limit swap
On 10/20/17 3:04 PM, Ferruh Yigit wrote:
On 10/12/2017 10:24 AM, Roger B Melton wrote:
When copying VLAN tags from the RX descriptor to the vlan_tci field
in the mbuf header, igb_rxtx.c:eth_igb_recv_pkts() and
eth_igb_recv_scattered_pkts() both assume that the VLAN tag is always
little endian
On 10/25/17 4:22 PM, Ferruh Yigit wrote:
On 10/25/2017 1:16 PM, Bruce Richardson wrote:
On Wed, Oct 25, 2017 at 11:11:08AM -0700, Ferruh Yigit wrote:
On 10/23/2017 10:42 AM, Roger B. Melton wrote:
On 10/20/17 3:04 PM, Ferruh Yigit wrote:
On 10/12/2017 10:24 AM, Roger B Melton wrote:
When
else {\
> + cur += (UINT_MAX - last) + latest; \
> + } \
> last = latest; \
>
cur += latest - last; \
> + } else { \
> + cur += (UINT_MAX - last) + latest;\
> + } \
> last = latest;\
> }
>
--
___
the calculation itself.
>
> So the correct way to compute this would be "cur += (latest - last) &
> UINT_MAX". Also the mask approach should be faster as it avoids any
> conditional jumps.
>
> - Alex
> .
>
--
__
\
> uint32_t latest = IXGBE_READ_REG(hw, reg); \
> - cur += latest - last; \
> + cur += (latest-last) & UINT_MAX;\
> last = latest; \
> }
>
test;\
> }
>
> -
> #define IGB_FC_PAUSE_TIME 0x0680
> #define IGB_LINK_UPDATE_CHECK_TIMEOUT 90 /* 9s */
> #define IGB_LINK_UPDATE_CHECK_INTERVAL 100 /* ms */
--
____
|Roge
On 10/12/15 12:45 PM, Harry van Haaren wrote:
> Fix a misinterpretation of VF stats in ixgbe
>
> Signed-off-by: Harry van Haaren
Acked-by: Roger Melton
On 10/12/15 12:45 PM, Harry van Haaren wrote:
> Fix a misinterpreatation of VF statistic macro in e1000/igb.
>
> Signed-off-by: Harry van Haaren
Acked-by: Roger Melton
Hi folks,
With the addition of hot plug support we have been migrating away from
device discovery and attach at initialization time to a model where it
is controlled from a separate process. The separate process manages the
binding of devices to UIO and instructs the DPDK process when to
atta
Hi David,
On 11/13/15 3:49 AM, David Marchand wrote:
> Hello Roger,
>
> On Thu, Nov 12, 2015 at 11:43 PM, Roger B Melton <mailto:rmelton at cisco.com>> wrote:
>
> Hi folks,
>
> With the addition of hot plug support we have been migrating away
> fr
provan
> dprovan at bivio.net
>
> -Original Message-
> From: David Marchand [mailto:david.marchand at 6wind.com]
> Sent: Friday, November 13, 2015 12:50 AM
> To: Roger B Melton
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Making rte_eal_pci_probe() in rte_eal_init() o
t be simpler to have an option to disable the rte_eal_init()
time the probe. Would that address the issue with VFIO, prevent
automatically attaching to devices while permitting on demand attach?
Thanks again.
Regards,
-Roger
On 11/14/15 12:51 PM, David Marchand wrote:
> Hello Roger,
>
Hi David, in-line -Roger
On 11/16/15 4:46 AM, David Marchand wrote:
> Hello Roger,
>
> On Sun, Nov 15, 2015 at 3:45 PM, Roger B. Melton <mailto:rmelton at cisco.com>> wrote:
>
> I like the "-b all" and "-w none" idea, but I think it might be
Hi Thomas, in-line -Roger
On 11/17/15 10:46 AM, Thomas Monjalon wrote:
> 2015-11-17 08:56, Roger B. Melton:
>> Hi David, in-line -Roger
>>
>> On 11/16/15 4:46 AM, David Marchand wrote:
>>> Hello Roger,
>>>
>>> On Sun, Nov 15, 2015 at 3:45 PM,
David/Thomas, in-line -Roger
On 11/18/15 5:13 PM, Roger B. Melton wrote:
> Hi Thomas, in-line -Roger
>
> On 11/17/15 10:46 AM, Thomas Monjalon wrote:
>> 2015-11-17 08:56, Roger B. Melton:
>>> Hi David, in-line -Roger
>>>
>>> On 11/16/15 4:46
> +/**
> + * Set thread names.
> + *
> + * Macro to wrap `pthread_setname_np()` with a glibc version check.
> + * Only glibc >= 2.12 supports this feature.
> + *
> + * This macro only used for Linux, BSD does direct libc call.
> + * BSD libc version of function is `pthread_set_name_np()`.
> + */
On 11/25/15 9:03 AM, Thomas Monjalon wrote:
> 2015-11-25 08:51, Roger B. Melton:
>> Have you thought about a way to set thread name when glibc < 2.12. I
>> also ran into the problem recently and played around with prctl()
>> (Linux) to set thread (process) name. e.g
t; return -ENODEV;
> }
> - RTE_ETH_FPTR_OR_ERR_RET(*dev->dev_ops->rx_descriptor_done, -ENOTSUP);
> #endif
> + RTE_ETH_FPTR_OR_ERR_RET(*dev->dev_ops->rx_descriptor_done, -ENOTSUP);
>
> return (*dev->dev_ops->rx_descriptor_done)( \
>
in eth_vmxnet3_dev_init(), to prevent stop
processing.
Signed-off-by: Roger B Melton
---
drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c
b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index 467fb61137..8d7f95a753 100644
--- a/driv
43 matches
Mail list logo
