https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270964
Mark Linimon changed:
What|Removed |Added
Keywords||IntelNetworking
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240023
Piotr Kubaj changed:
What|Removed |Added
Status|New |In Progress
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260427
e...@norma.perm.ru changed:
What|Removed |Added
Resolution|--- |Overcome By Events
...@freebsd.org|n...@freebsd.org
Summary|[regression]: netmap causes |netmap causes packet drops
|packet drops|
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260068
On Sat, Nov 20, 2021, 3:19 PM Özkan KIRIK wrote:
> Hello,
>
> I'm using stable/12 (aba2dc46dfa5, Oct 24 2021). I'm hitting some
> problems with if_vlan + parent interface netmap. It was working with
> before driver update.
Hello,
I'm using stable/12 (aba2dc46dfa5, Oct 24 2021). I'm hitting some
problems with if_vlan + parent interface netmap. It was working with
before driver update. Maybe something missing for netmap
implementation.
The way to reproduce:
[HostA] <> [HostB]
HostA
- ifconfig em1.110
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230465
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230465
--- Comment #47 from Vincenzo Maffione ---
What is the state of the TX ring (head, cur, tail) when stalling?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230465
--- Comment #46 from strongs...@nanoteq.com ---
(In reply to strongswan from comment #45)
I did some more testing, and even with the setting hw.ixl.enable_head_writeback
= 0 I still get to a situation where no packets are transmitted.
There
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230465
--- Comment #44 from Vincenzo Maffione ---
What if you set
hw.ixl.enable_head_writeback = 0
in /boot/loader.conf and reboot?
--
You are receiving this mail because:
You are on the CC list for the bug.
from s...@zxy.spb.ru ---
(In reply to Vincenzo Maffione from comment #42)
Looks like netmap don't worked:
# /usr/obj/usr/src/amd64.amd64/tools/tools/netmap/pkt-gen -i ixl1 -f tx
321.990539 main [2921] interface is ixl1
321.990568 main [3044] using default burst size: 512
321.990573 main [3052
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255671
--- Comment #2 from Brian Poole ---
Hello Ozkan,
Thank you very much for your comment! I have not seen any failures in tx/rx or
tx/tx configurations since setting hw.ixl.enable_head_writeback=0. Now that I
know what to search for, I found
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255671
Mark Linimon changed:
What|Removed |Added
Keywords||IntelNetworking
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255671
Ozkan KIRIK changed:
What|Removed |Added
CC||ozkan.ki...@gmail.com
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255671
Lutz Donnerhacke changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are
gt; Cheers,
>> Vincenzo
>>
>> Il giorno lun 29 mar 2021 alle ore 10:36 Özkan KIRIK <
>> ozkan.ki...@gmail.com> ha scritto:
>>
>>> Hello,
>>>
>>> I hit problems about ixl driver's netmap support. I have no problems with
>>> ixgbe.
>&g
gt; https://reviews.freebsd.org/D26896?
>
> Moreover, what happens if you switch the enable_head_writeback sysctl?
>
> Cheers,
> Vincenzo
>
> Il giorno lun 29 mar 2021 alle ore 10:36 Özkan KIRIK <
> ozkan.ki...@gmail.com> ha scritto:
>
>> Hello,
>>
>&
Hi,
Could this be related to
https://reviews.freebsd.org/D26896?
Moreover, what happens if you switch the enable_head_writeback sysctl?
Cheers,
Vincenzo
Il giorno lun 29 mar 2021 alle ore 10:36 Özkan KIRIK
ha scritto:
> Hello,
>
> I hit problems about ixl driver's netmap suppor
Hello,
I hit problems about ixl driver's netmap support. I have no problems with
ixgbe.
The problem is tested with FreeBSD 12.2-p5 and FreeBSD 13.0-RC3.
ixl in netmap mode, it works with low throughput (about 2 Gbps) for 20-30
seconds. And then TX queue remains full. poll with POLLOUT and even
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230465
--- Comment #42 from Vincenzo Maffione ---
(In reply to Charles Goncalves from comment #41)
I don't have a test environment either.
But since ixl uses iflib on 12.x and 13.x, I expected this issue has gone away.
--
You are receiving this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230465
--- Comment #41 from Charles Goncalves ---
(In reply to Vincenzo Maffione from comment #40)
Hello Vincenzo!
This issue is present on FreeBSD 12.2 or 13.0? I don't have a test environment
right now, but I will upgrade a production router
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230465
Charles Goncalves changed:
What|Removed |Added
Version|11.2-STABLE |12.1-STABLE
--
You are
On Wed, Dec 16, 2020 at 9:53 PM Vincenzo Maffione
wrote:
>
> On a side note, the netmap tools (pkt-gen, bridge, lb, etc.) should really
> be a port. Another TODO item.
>
>
There is already one port for an old version of pkt-gen:
https://svnweb.freebsd.org/ports/head/net/pkt
usr/obj helps to get past the issue. But not sure why libnetmap is not
built and installed though "device netmap" is set in the config file.
Manually copying may not be the right approach. Can anyone suggest a
cleaner way of getting things done?
Thanks,
Rajesh.
On Wed, Dec 16, 2020
Hi,
I am trying to compile the netmap tools(pkt-gen, bridge etc.,) and getting
the below error.
*/root//freebsd/tools/tools/netmap/pkt-gen.c:47:10: fatal error:
'libnetmap.h' file not found#include ^1
error generated.*** Error code 1*
On debug, I don't see
arting from ping
packets due to incompatibility with Iflib/Netmap and associated utilities.
I made some changes to the driver, Iflib and Netmap utilities and having
the netmap bridge working with axgbe now.
I am working on a clean fix for promisc mode setting and incompatibility
issue. Will submit the
Hi Vincenzo,
Thanks for pointing this.
On Sat, Nov 21, 2020 at 10:40 PM Vincenzo Maffione
wrote:
> # ifconfig ix0 promisc
> # ifconfig ix1 promisc
>
> This is an additional requirement when using netmap bridge, because that
> is not done automatically (differently fr
Hi Rajesh,
I think the issue here is simply that you have not enabled promiscuous
mode on your interfaces.
# ifconfig ix0 promisc
# ifconfig ix1 promisc
This is an additional requirement when using netmap bridge, because that is
not done automatically (differently from what happens
Il giorno ven 20 nov 2020 alle ore 14:31 Rajesh Kumar
ha scritto:
> Hi Vincenzo,
>
> On Fri, Nov 20, 2020 at 3:20 AM Vincenzo Maffione
> wrote:
>
>>
>> Ok, now it makes sense. Thanks for clarifying. I see that if_axp(4) uses
>> iflib(4). This means that act
Hi Vincenzo,
On Fri, Nov 20, 2020 at 3:20 AM Vincenzo Maffione
wrote:
>
> Ok, now it makes sense. Thanks for clarifying. I see that if_axp(4) uses
> iflib(4). This means that actually if_axp(4) has native netmap support,
> because iflib(4) has native netmap support.
>
>
It mea
Il giorno gio 19 nov 2020 alle ore 12:28 Rajesh Kumar
ha scritto:
> Hi Vincenzo,
>
> Thanks for your reply.
>
> On Thu, Nov 19, 2020 at 3:16 AM Vincenzo Maffione
> wrote:
>
>>
>> This looks like if_axe(4) driver, and therefore there's no native netmap
>&g
Hi Vincenzo,
Thanks for your reply.
On Thu, Nov 19, 2020 at 3:16 AM Vincenzo Maffione
wrote:
>
> This looks like if_axe(4) driver, and therefore there's no native netmap
> support, which means you are falling back on
> the emulated netmap adapter. Are these USB dongles? If
Hi,
Il giorno mer 18 nov 2020 alle ore 08:13 Rajesh Kumar
ha scritto:
> Hi,
>
> I am testing a 10G Network driver with Netmap "bridge" utility, where it
> doesn't seem to work. Here is my setup details.
>
> *System under Test:* Running FreeBSD CURRENT. Has
Hi,
I am testing a 10G Network driver with Netmap "bridge" utility, where it
doesn't seem to work. Here is my setup details.
*System under Test:* Running FreeBSD CURRENT. Has two inbuilt 10G NIC
ports.
*System 1:* Running Ubuntu, whose network port is connected to Port1 of
System
iflib: add per-tx-queue netmap timer
The way netmap TX is handled in iflib when TX interrupts are not
used (IFC_NETMAP_TX_IRQ not set) has some issues:
- The netmap_tx_irq() function gets called by iflib_timer(), which
gets scheduled with tick granularity (hz). This is not frequent
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247647
Zhenlei Huang changed:
What|Removed |Added
Status|In Progress |Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #46 from commit-h...@freebsd.org ---
A commit references this bug:
Author: vmaffione
Date: Wed Oct 28 21:06:18 UTC 2020
New revision: 367117
URL: https://svnweb.freebsd.org/changeset/base/367117
Log:
iflib: fix typo bug
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #45 from Vincenzo Maffione ---
(In reply to Sylvain Galliano from comment #43)
Ugh.
Thanks for reporting.
I indeed introduced a subtle typo bug, using callout_reset_sbt() rather than
callout_reset_sbt_on() (as intended).
||
--- Comment #44 from Vincenzo Maffione ---
Created attachment 219179
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=219179=edit
Cleaned up netmap tx timer (bugfixes)
--
You are receiving this mail because:
You are on the CC list for the
0xfe0008480cf0
fork_exit() at fork_exit+0x7e/frame 0xfe0008480d30
fork_trampoline() at fork_trampoline+0xe/frame 0xfe0008480d30
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
I used the first patch you sent (Draft patch to test the netmap tx timer), no
issue this time.
the only major difference I can
netmap timer
The way netmap TX is handled in iflib when TX interrupts are not
used (IFC_NETMAP_TX_IRQ not set) has some issues:
- The netmap_tx_irq() function gets called by iflib_timer(), which
gets scheduled with tick granularity (hz). This is not frequent
enough for 10Gbps
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
Vincenzo Maffione changed:
What|Removed |Added
Status|Open|In Progress
--- Comment #41
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #40 from Sylvain Galliano ---
(In reply to Vincenzo Maffione from comment #39)
results are all good for ix (X520) NIC (+14M pps, same as FreeBSD 11)
No changes in ixl (same results as comment #16)
--
You are receiving this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #39 from Vincenzo Maffione ---
(In reply to Sylvain Galliano from comment #37)
Ok thanks. It was worth a try. I guess we'll need some help from Intel here.
In the meanwhile, I would like to commit the netmap tx timer change
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #38 from Vincenzo Maffione ---
Created attachment 219121
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=219121=edit
Cleaned up netmap tx timer patch (no sysctl)
--
You are receiving this mail because:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #37 from Sylvain Galliano ---
(In reply to Vincenzo Maffione from comment #36)
I have tested last patch (netmap tx timer w/queue intr enable + honor
IPCP_TX_INTR in ixl_txd_encap): same results
--
You are receiving this mail
, in the last patch I also add the enable_queue step in the netmap
timer routine. It may be worth giving a try to see if this fixes the ixl issue.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #35 from Vincenzo Maffione ---
Created attachment 219062
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=219062=edit
netmap tx timer w/queue intr enable + honor IPCP_TX_INTR in ixl_txd_encap
Extension of the last
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #34 from Vincenzo Maffione ---
(In reply to Sylvain Galliano from comment #33)
Ok, thanks. At this point it's clear that there are two indipendent issues that
slow down netmap-iflib on ix/ixl. The first is the lack of a per-tx
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #33 from Sylvain Galliano ---
(In reply to Vincenzo Maffione from comment #32)
Here are the results:
ixl only patch, 6 queues, pkt-get WITHOUT -R:
710.623764 main_thread [2642] 38.621 Mpps (38.698 Mpkts 18.538 Gbps in 1002000
please try to test what happens if you only apply the ixl patch
(discarding all the changes related to the netmap timer)?
In the very end the change to ixl is orthogonal to the netmap timer issue.
Also, it would be useful to understand whether the hang problem comes from some
sort of race condition
could run some tests to validate the change
against normal TCP/IP stack usage (e.g. non-netmap).
Speaking about the non-iflib driver, I guess it is acceptable for the ixl_xmit
routine to always set the report flag on the EOP packet.
However, this is not acceptable for netmap, and indeed the non-iflib
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
Krzysztof Galazka changed:
What|Removed |Added
CC||krzysztof.gala...@intel.com
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #29 from Sylvain Galliano ---
(In reply to Vincenzo Maffione from comment #28)
Yes, this is much better:
6 queues, nm_tx_tmr_us=5:
983.492185 main_thread [2639] 37.907 Mpps (37.945 Mpkts 18.196 Gbps in 1001000
usec) 512.00
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #28 from Vincenzo Maffione ---
(In reply to Sylvain Galliano from comment #26)
Thanks.
I just figured out that there may be a major flaw introduced by the porting of
ixl to iflib. This flaw should couse too many writebacks
||
--- Comment #27 from Vincenzo Maffione ---
Created attachment 218932
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=218932=edit
netmap tx timer + honor IPI_TX_INTR in ixl txd_encap
Adds an unrelated fix on top of the first patch (218723).
The new fix should rem
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #26 from Sylvain Galliano ---
(In reply to Vincenzo Maffione from comment #25)
you are correct, using 1 queue on both ix/ixl NIC + tuning new sysctl, we have
same result as FreeBSD 11
Regarding avg_batch values on ixl, they
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #25 from Vincenzo Maffione ---
Sorry, my bad.
I read the code the wrong way, so the second patch is indeed useless. Please
forget about that. The patch is not ensuring timely TX slots recovery (as
pointed out in comment #23).
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #24 from Sylvain Galliano ---
(In reply to Vincenzo Maffione from comment #23)
After using 'Netmap tx timer + timely credits update' patch, I didn't notice
any difference on results.
Should I make some specific tests
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #23 from Vincenzo Maffione ---
(In reply to Sylvain Galliano from comment #21)
Thanks.
The CPU utilization at least tells us that we are not CPU bound.
Could you please perform some tests with the second patch?
It's basically
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #22 from Vincenzo Maffione ---
Created attachment 218866
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=218866=edit
Netmap tx timer + timely credits update
A small extension of the previous patch, which adds
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #21 from Sylvain Galliano ---
(In reply to Vincenzo Maffione from comment #19)
result using 1 queue:
ixl1: PCI Express Bus: Speed 8.0GT/s Width x8
ixl1: netmap queues/slots: TX 1/1024, RX 1/1024
sysctl dev.ixl.0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #20 from Vincenzo Maffione ---
(In reply to vistalba from comment #17)
Of course you will need to apply the attached patch before "make kernel", e.g.
$ cd /path/to/freebsd/kernel/sources
$ patch -p1 <
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #19 from Vincenzo Maffione ---
(In reply to Sylvain Galliano from comment #16)
Thanks a lot.
In the XL710 case, have you tried with lower values of the timer, such as 50us
down to 5 us?
Is there any visible change?
Also, have
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #18 from Michael Muenz ---
(In reply to vistalba from comment #17)
- Install Vanilla FreeBSD12
- pkg install git
- cd /usr && git clone https://github.com/opnsense/tools
- cd tools && make update
- make kernel
You can also
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #17 from vistalba ---
(In reply to Vincenzo Maffione from comment #14)
Is there a easy way to test this on my opnsense vm with vmx interfaces. As far
as I know my netmap issue on vmx is related to this timer issue as well.
I'm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #16 from Sylvain Galliano ---
(In reply to Vincenzo Maffione from comment #14)
Here are the results:
X520 with 1 queue
ix0: PCI Express Bus: Speed 5.0GT/s Width x8
ix0: netmap queues/slots: TX 1/2048, RX 1/2048
|Affects Only Me |Affects Some People
Summary|netmap: pkt-gen TX huge pps |iflib: netmap pkt-gen large
|difference between |TX performance difference
|11-STABLE and |between 11-STABLE and
|12-STABLE
--- Comment #14 from Vincenzo Maffione ---
Created attachment 218723
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=218723=edit
Draft patch to test the netmap tx timer
This is a draft patch that adds support for a per-tx-queue timer dedicated to
netmap.
The timer interval is st
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #13 from Vincenzo Maffione ---
(In reply to vistalba from comment #12)
I started to work on it, however I've no suitable hardware to test.
This means that I will need to patch qemu to modify the emulation of an
iflib-backed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
vistalba changed:
What|Removed |Added
CC||regis...@kad-it.ch
--- Comment #12
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #11 from Vincenzo Maffione ---
(In reply to Eric Joyner from comment #10)
Not yet. I've been AFK for a couple of weeks. I should be able to work on it
this week.
--
You are receiving this mail because:
You are the assignee
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
Eric Joyner changed:
What|Removed |Added
CC||e...@freebsd.org
--- Comment #10
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #9 from Vincenzo Maffione ---
Thanks a lot for the tests.
I think the way netmap tx is handled right now needs improvement.
As far as I can tell, in your setup TX interrupts are simply not used (ix and
ixl seem to use softirq
h x8
ix0: netmap queues/slots: TX 1/2048, RX 1/2048
*
/boot/loader.conf:
kern.hz=1000 (default)
pkt-gen result:
204.153802 main_thread [2639] 2.562 Mpps (2.567 Mpkts 1.230 Gbps in 1001994
usec) 465.32 avg_batch 9 min_space
205.155321 main_thread [2639] 2.561 Mpps (2.565 Mpkts 1
unrelated, since it mentions netmap with ixl in 12.x, where
iflib is in use. There was an iflib/netmap bug (see
https://reviews.freebsd.org/D25252) that may explain the problems briefly
mentioned in #37. But that is now in HEAD and stable/12.
This report is about a bug that apparently affects netmap TX
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #7 from Vincenzo Maffione ---
(In reply to Kubilay Kocak from comment #6)
I would say
ix/ixl and/or NIC driver & iflib
because it's not something related to the netmap module itself, and it is an
optimization which der
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230465
Kubilay Kocak changed:
What|Removed |Added
See Also||https://github.com/OISF/sur
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230465
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #6 from Kubilay Kocak ---
(In reply to Vincenzo Maffione from comment #5)
Is this more specific/scoped to:
- netmap & iflib, or
- ix/ixl and/or NIC driver & iflib, or
- iflib framework (generally)
--
You are r
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #5 from Vincenzo Maffione ---
Ok, thanks for the feedback. That means that the issue is that iflib is not
asking enough TX descriptor writebacks. Need for some investigation in the
iflib txsync routine.
--
You are receiving
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #4 from Sylvain Galliano ---
You're right, interrupt rate limit pps on CURRENT + X520 NIC:
pkt-gen, no busy wait
11-stable: 27500 irq/s
CURRENT:5500 irq/s
pkt-gen, with busy wait on CURRENT: +3 irq/s
Regarding NIC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #3 from Vincenzo Maffione ---
It looks like you get 2.6 Mpps because you are not getting enough interrupts...
have you tried to measure the interrupt rate in the two cases (current vs 11,
no busy wait)?
Intel NICs have tunables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
Kubilay Kocak changed:
What|Removed |Added
Keywords||iflib
Flags|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #2 from Sylvain Galliano ---
Hi Vincenzo, thanks for your quick reply.
I've disabled all offloads in both 11-STABLE and CURRENT and I got the same
results.
I did another test that may help you:
I've recompiled pkt-gen on
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #1 from Vincenzo Maffione ---
Thanks for reporting.
What I can tell you for sure is that the difference is to be attributed to the
conversion of Intel drivers (em, ix, ixl) to iflib.
This impacted netmap because netmap support
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
Kubilay Kocak changed:
What|Removed |Added
Summary|[netmap]: pkt-gen tx huge |netmap: pkt-gen TX huge pps
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
Kubilay Kocak changed:
What|Removed |Added
CC||n...@freebsd.org,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247647
Kubilay Kocak changed:
What|Removed |Added
Flags|mfc-stable12? |mfc-stable12+
See Also|
: initialize netmap with the correct number of descriptors
In case the network device has a RX or TX control queue, the correct
number of TX/RX descriptors is contained in the second entry of the
isc_ntxd (or isc_nrxd) array, rather than in the first entry.
This case is correctly handled
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247647
--- Comment #25 from Murat ---
(In reply to Vincenzo Maffione from comment #24)
Thanks for the update.
Yes, we've confirmed that this fix resolved kernel crash with vmx.
I will try to test with ix(4) soon.
--
You are receiving this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247647
--- Comment #24 from Vincenzo Maffione ---
(In reply to Murat from comment #22)
It is possible that the same bug caused a crash also on ix(4).
Have you tested if the patch makes the bug go away?
--
You are receiving this mail because:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236584
--- Comment #10 from Murat ---
Created attachment 217047
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=217047=edit
dmesg.boot file for the test PC
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236584
--- Comment #9 from Murat ---
Created attachment 217046
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=217046=edit
em vlanhwtag patch tests
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236584
--- Comment #8 from Murat ---
Hi Vincenzo,
Sorry, my bad. Working with different source bases now, I had a look at another
directory.
I've done some tests on an HP Compaq 6305 SFF Desktop.
Test results and HW configuration is attached.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247647
--- Comment #23 from Murat ---
Follow-up ticket: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248494
--
You are receiving this mail because:
You are on the CC list for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247647
--- Comment #22 from Murat ---
Vincenzo, thanks. I'll create another ticket for that.
As for the kernel crash, any possibility that this bug was also affecting
ix(4). We saw a similar crash with that one too.
--
You are receiving this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247647
--- Comment #21 from Vincenzo Maffione ---
I'm pretty sure what you see is the effect of a separate bug.
It's a regression introduced by porting netmap to iflib. It shows up with those
devices that use multiple "free lists" on t
do some tests on real em hardware, to check the patch does
not introduce any regression, independently on netmap, I will gladly merge this
into HEAD.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247647
--- Comment #20 from Zhenlei Huang ---
Hi Murat,
Sorry I'm not familiar with such bridge configuration. It seems to be a
different issue that masked by this one. CC Vincenzo Maffione.
--
You are receiving this mail because:
You are on
1 - 100 of 1229 matches
Mail list logo
