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 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
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:
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
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_
- 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
- 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,
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
,
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
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
- 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
>&
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 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
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 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
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
- 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
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
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
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
> 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
> 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
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
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
- 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
>
- 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
>
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'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
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:
>>
- 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
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
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
fbdev is now runnin FreeBSD 14.2.
The former version (14.1) is now running on fbdev141.
Thanks,
lew
34 matches
Mail list logo
