sible. So the only thing contigmem is doing for us on FreeBSD is providing
the physical address and, of course, making it consistent with Linux.
At least, that's my understanding.
- On Oct 28, 2024, at 8:26 AM, Dmitry Kozlyuk dmitry.kozl...@gmail.com
wrote:
> 2024-10-26 06:43 (UTC
Is the extra control necessary, i.e., why not just always do this and let the
EAL option control whether the pages get dumped?
- On Oct 25, 2024, at 3:26 PM, Dmitry Kozlyuk dmitry.kozl...@gmail.com
wrote:
> It was impossible to include mapped contigmem buffers in core dump.
> Add hw.contigm
- On Oct 23, 2024, at 6:18 PM, Dmitry Kozlyuk dmitry.kozl...@gmail.com
wrote:
> Lewis, testing on FreeBSD would be appreciated.
Well, unfortunately, it's not working very well... The contigmem memory was
not included in the core dump.
I added logging just before the madvise() call to pr
- On Oct 22, 2024, at 10:39 AM, Stephen Hemminger
step...@networkplumber.org wrote:
> On Tue, 22 Oct 2024 17:47:11 +0300
> Dmitry Kozlyuk wrote:
>
>> 2024-10-22 07:41 (UTC-0500), Lewis Donzis:
>> > I've been wondering why we exclude memory allocated by
>
- On Oct 22, 2024, at 10:34 AM, Stephen Hemminger
step...@networkplumber.org wrote:
> On Tue, 22 Oct 2024 09:42:05 -0500
> l...@perftech.com wrote:
>
>> From: Lewis Donzis
>>
>> Forcing wait true prevents checking link status without delay, because the
>
Certainly. This is my first attempt and I didn't realize some of the rules,
but hopefully it'll work.
Thanks,
lew
- On Oct 22, 2024, at 8:03 AM, Bruce Richardson bruce.richard...@intel.com
wrote:
> On Tue, Oct 22, 2024 at 07:32:01AM -0500, Lewis Donzis wrote:
>>
I've been wondering why we exclude memory allocated by eal_get_virtual_area()
from core dumps? (More specifically, it calls eal_mem_set_dump() to call
madvise() to disable core dumps from the allocated region.)
On many occasions, when debugging after a crash, it would have been very
convenient
I've reported this several times over the last two years, but there's been no
reply and no change to the ixgbe driver.
Specifically, calling rte_eth_link_get_nowait() on FreeBSD does, in fact, wait
for link-up which causes unexpected and long delays.
I suggest removing the line from ixgbe_dev_l
I'm pretty sure this is been reported before, but in ixgbe_ethdev.c, line 4311
begins:
/* BSD has no interrupt mechanism, so force NIC status synchronization. */
#ifdef RTE_EXEC_ENV_FREEBSD
wait = 1;
#endif
We've had to remove this code ever since it was added because it causes
improper
- On May 28, 2024, at 1:55 AM, Dmitry Kozlyuk dmitry.kozl...@gmail.com
wrote:
> Hi Lewis,
>
> Memory reserved by eal_get_virtual_area() is not yet useful,
> but it is very large, so by excluding it from dumps,
> DPDK prevents dumps from including large zero-filled parts.
>
> It also makes
I've been wondering why we exclude memory allocated by eal_get_virtual_area()
from core dumps? (More specifically, it calls eal_mem_set_dump() to call
madvise() to disable core dumps from the allocated region.)
On many occasions, when debugging after a crash, it would have been very
convenient
I keep meaning to mention this because we've been patching the ixgbe driver for
a while...
In ixgbe_ethdev.c, function ixgbe_dev_link_update_share(), we find the
following:
/* BSD has no interrupt mechanism, so force NIC status synchronization. */
#ifdef RTE_EXEC_ENV_FREEBSD
wait = 1
- On Jan 24, 2024, at 7:58 AM, Ferruh Yigit ferruh.yi...@amd.com wrote:
> On 1/24/2024 12:34 PM, Lewis Donzis wrote:
>
>> - On Jan 11, 2024, at 6:03 AM, Ferruh Yigit ferruh.yi...@amd.com wrote:
>>
>>> On 1/9/2024 4:00 PM, Lewis Donzis wrote:
>>>&g
Did this get checked in?
Just curious because I don't see it in 22.11.4 that was released yesterday, so
wasn't sure when it would show up.
Thanks,
lew
- On Jan 11, 2024, at 6:03 AM, Ferruh Yigit ferruh.yi...@amd.com wrote:
> On 1/9/2024 4:00 PM, Lewis Donzis wrote:
>>
- On Jan 9, 2024, at 5:55 PM, Stephen Hemminger step...@networkplumber.org
wrote:
> Probably need to go further with this.
> - what about unreigster in vmxnet3_dev_stop
> - vmxnet3_interrupt_handler is then dead code, should it be #ifdef guarded?
> - and vmxnet3_dev_rx_queue_intr_enable/dis
n building for FreeBSD,
> allowing the driver to initialize correctly.
>
> Fixes: 046f11619567 ("net/vmxnet3: support MSI-X interrupt")
>
> Reported-by: Lewis Donzis
Tested-by: Lewis Donzis
> Signed-off-by: Bruce Richardson
> ---
> drivers/net/vmxnet3/vmxnet3_
- On Jan 9, 2024, at 8:28 AM, Bruce Richardson bruce.richard...@intel.com
wrote:
> On Tue, Jan 09, 2024 at 07:46:47AM -0600, Lewis Donzis wrote:
>> Hi, Bruce.
>>
>> I'm even less familiar with it, but we do quite a lot of testing using VMs,
>> so
>&
Hi, Bruce.
I'm even less familiar with it, but we do quite a lot of testing using VMs, so
it's been quite handy.
Your patch seems very reasonable, however it also produces a warning:
../drivers/net/vmxnet3/vmxnet3_ethdev.c:264:1: warning: unused function
'vmxnet3_enable_all_intrs' [-Wunused-fu
,
lew
- On Jun 3, 2022, at 8:19 AM, Lewis Donzis l...@perftech.com wrote:
> Hi, all.
>
> Resurrecting this thread from six months ago, I apologize for not having more
> time to dig into it, but in light of recent findings, I see numerous other
> drivers and other parts of the code t
yev
konstantin.anan...@intel.com wrote:
>> -Original Message-
>> From: Richardson, Bruce
>> Sent: Monday, December 6, 2021 9:17 AM
>> To: Lewis Donzis
>> Cc: dev ; Wang, Yong ; Ananyev, Konstantin
>>
>> Subject: Re: vmxnet3 no longer functional on DPD
Using DPDK 21.11.1 on FreeBSD 13.1, calling rte_eth_link_get_nowait() appears
to hang waiting for the link to come up on an XL710 or 82599 based NIC.
This call eventually makes its way to ixgbe_dev_link_update_share() with
wait_to_complete set to false.
Inside that function, there is this code:
- On May 30, 2022, at 3:09 AM, Bruce Richardson bruce.richard...@intel.com
wrote:
> On Sun, May 29, 2022 at 06:36:21AM -0500, Lewis Donzis wrote:
>> Apparently FreeBSD 13.1 changed the syntax of the CPUSET macros, so DPDK no
>> longer compiles.
>>
>> For exampl
Apparently FreeBSD 13.1 changed the syntax of the CPUSET macros, so DPDK no
longer compiles.
For example, here's one definition on FreeBSD 13.0 and prior:
CPU_OR(cpuset_t *dst, cpuset_t *src);
and here it is in FreeBSD 13.1:
CPU_OR(cpuset_t *dst, cpuset_t *src1, cpuset_t *src2);
I'
- On Dec 6, 2021, at 6:08 AM, Ananyev, Konstantin
konstantin.anan...@intel.com wrote:
> So to clarify, it fails at:
> static int
> vmxnet3_dev_start(struct rte_eth_dev *dev)
> {
> ...
> line 1695:
> if (rte_intr_enable(dev->intr_handle) < 0) {
>PMD_INIT_LOG(ERR,
- On Nov 30, 2021, at 7:42 AM, Bruce Richardson bruce.richard...@intel.com
wrote:
> On Mon, Nov 29, 2021 at 02:45:15PM -0600, Lewis Donzis wrote:
>>Hello.
>>We just upgraded from 21.08 to 21.11 and it's rather astounding the
>>number of incompatib
Hello.
We just upgraded from 21.08 to 21.11 and it's rather astounding the number of
incompatible changes in three months. Not a big deal, just kind of a surprise,
that's all.
Anyway, the problem is that the vmxnet3 driver is no longer functional on
FreeBSD.
In drivers/net/vmxnet3/vmxnet3_
rn ret;
---
> return 0;
181c184,185
< TAILQ_REMOVE(&(src->callbacks), callback, next);
---
> if (callback != NULL)
> TAILQ_REMOVE(&(src->callbacks), callback, next);
- On Aug 3, 2020, at 6:22 PM, Honnappa Nagara
Hello.
We've posted about this before, but I'm hoping to find someone willing to
commit a patched version of lib/librte_eal/bsdapp/eal/eal_interrupts.c that
corrects a memory leak and 100% CPU hog that is immediately noticeable with the
i40e driver, at a minimum. We have modified this file to
Please consider changing "struct ether_addr" in rte_ether.h to "struct
rte_ether_addr", in order to avoid conflicts with the same structure name
/usr/include/net/ethernet.h.
Sometimes, there is need to include /usr/include/net/ethernet.h, but it
conflicts with the same structure name in rte_eth
Please consider changing “struct ether_addr” in rte_ether.h to “struct
rte_ether_addr”, in order to avoid conflicts with the same structure name
/usr/include/net/ethernet.h.
This is kind of a pain for us since we would like to include ethernet.h in
order to get some other definitions, but we ca
> On Nov 4, 2016, at 11:38 AM, Sergio Gonzalez Monroy at intel.com> wrote:
> It should have been fixed in 16.07.1.
> http://dpdk.org/browse/dpdk-stable/commit/?id=82f931805506efbb8b5046e9045bec8f04bbabf6
Hi, Sergio.
We confirmed that it works perfectly with 16.07.1 with the new contigmem driver
> On Nov 4, 2016, at 11:38 AM, Sergio Gonzalez Monroy at intel.com> wrote:
>
> On 03/11/2016 20:04, Lewis Donzis wrote:
>> I?m curious about how/whether this got resolved. The 16.07.1 code doesn?t
>> appear to have this fixed.
>>
>> Is it still forthc
I?m curious about how/whether this got resolved. The 16.07.1 code doesn?t
appear to have this fixed.
Is it still forthcoming?
Thanks,
lew
33 matches
Mail list logo
