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 receivi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255671
Ozkan KIRIK changed:
What|Removed |Added
CC||ozkan.ki...@gmail.com
--- Comment #1
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 re
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #47 from commit-h...@freebsd.org ---
A commit references this bug:
Author: vmaffione
Date: Wed Nov 11 21:27:17 UTC 2020
New revision: 367599
URL: https://svnweb.freebsd.org/changeset/base/367599
Log:
MFC r367093, r367117
i
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 intro
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). Theref
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
Vincenzo Maffione changed:
What|Removed |Added
Attachment #219121|0 |1
is obsolete|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #43 from Sylvain Galliano ---
I made same tests on vmware + vmxnet NIC + latest patch and I got a panic:
spin lock 0xf80003079cc0 (turnstile lock) held by 0xfe0009607e00 (tid
16) too long
panic: spin lock held too l
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #42 from commit-h...@freebsd.org ---
A commit references this bug:
Author: vmaffione
Date: Tue Oct 27 21:53:33 UTC 2020
New revision: 367093
URL: https://svnweb.freebsd.org/changeset/base/367093
Log:
iflib: add per-tx-queue n
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
Vincenzo Maffione changed:
What|Removed |Added
Status|Open|In Progress
--- Comment #41 fr
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 m
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 onl
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&action=edit
Cleaned up netmap tx timer patch (no sysctl)
--
You are receiving this mail because:
You are
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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #36 from Vincenzo Maffione ---
(In reply to Vincenzo Maffione from comment #35)
I would ask for advice from the Intel guys here...
I'm trying to compare stable/11 vs current, regarding how TX interrupts are
handled. It looks lik
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&action=edit
netmap tx timer w/queue intr enable + honor IPCP_TX_INTR in ixl_txd_encap
Extension of the la
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-q
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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #32 from Vincenzo Maffione ---
(In reply to Sylvain Galliano from comment #29)
Thanks again for your tests.
I'm inclined to think that the pkt-gen hang issue that you see is not directly
caused by the ixl patch.
Would you pleas
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #31 from Vincenzo Maffione ---
(In reply to Krzysztof Galazka from comment #30)
Hi Krzysztof,
I agree, and created a separate review for this possible change:
https://reviews.freebsd.org/D26896
It would be nice if you guys cou
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 avg
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 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
Vincenzo Maffione changed:
What|Removed |Added
Attachment #218866|0 |1
is obsolete|
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 ar
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).
S
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 to confirm
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 th
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&action=edit
Netmap tx timer + timely credits update
A small extension of the previous patch, which adds u
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.iflib.nm_tx_t
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 < /path/to/attached/patch
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 jus
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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
Vincenzo Maffione changed:
What|Removed |Added
Assignee|n...@freebsd.org |vmaffi...@freebsd.org
--- Com
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 dev
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
vistalba changed:
What|Removed |Added
CC||regis...@kad-it.ch
--- Comment #12 from
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 fo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
Eric Joyner changed:
What|Removed |Added
CC||e...@freebsd.org
--- Comment #10 fro
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 f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
--- Comment #8 from Sylvain Galliano ---
After looking at iflib_netmap_timer_adjust() & iflib_netmap_txsync() in
sys/net/iflib.c,
I made some tuning on kern.hz:
Still using X520 with 1 queue
ix0: PCI Express Bus: Speed 5.0GT/s Width x8
ix0
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 derives fro
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 receiving th
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 th
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 curr
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 f
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,
Hello Vincenzo,
Friday, November 2, 2018, 5:43:16 PM, you wrote:
> It looks like there is not enough memory for netmap to allocate its data
> structures.
And with latest pkt-gen from github I get this:
240.075736 [2096] netmap_ioctl API mismatch for igb1 got 12 need 11
Why?! H
On 02.11.2018 17:43, Vincenzo Maffione wrote:
> It looks like there is not enough memory for netmap to allocate its
> data structures.
I didn't tune anything in this area
> What is the output of
>
> # sysctl dev.netmap
# sysctl dev.netmap
dev.netmap.iflib_rx_miss_bufs: 0
dev.netmap.iflib_rx_
Hi,
It looks like there is not enough memory for netmap to allocate its data
structures.
What is the output of
# sysctl dev.netmap
?
Cheers,
Vincenzo
Il giorno ven 2 nov 2018 alle ore 14:02 Lev Serebryakov
ha scritto:
> On 02.11.2018 14:31, Lev Serebryakov wrote:
>
>
> > $ sudo ./pkt-gen
On 02.11.2018 14:31, Lev Serebryakov wrote:
> $ sudo ./pkt-gen -f rx -i igb1
and pkt-gen from ports complains about invalid interface:
622.603767 main [2699] interface is igb1
622.603783 main [2824] using default burst size: 512
622.603786 main [2832] running on 1 cpus (have 4)
622.603841 extra
I'm trying to use "pkt-gen" on 11.2-STABLE r339914, with I210 (igb) adapter.
I'm starting
$ sudo ./pkt-gen -f rx -i igb1
193.634286 main [1731] interface is igb1
193.634342 extract_ip_range [293] range is 10.0.0.1:0 to 10.0.0.1:0
193.634347 extract_ip_range [293] range is 10.1.0.1:0 to 10.1.0.
You can suppress the warning with something like this:
# cd /usr/src/tools/tools/netmap
# WARNS=2 make
Regards,
Navdeep
On Tue, May 30, 2017 at 10:54 AM, Harry Schmalzbauer wrote:
> Hello,
>
> after merging netmap code from head I can't compile pkt-gen from
> usr/src/tools/tools/netmap:
> cc
Hello,
after merging netmap code from head I can't compile pkt-gen from
usr/src/tools/tools/netmap:
cc -O2 -pipe -Werror -Wall -Wextra -march=ivybridge -g -std=gnu99
-fstack-protector-strong-Qunused-arguments -Qunused-arguments
-std=gnu99 -fstack-protector-strong-Qunused-arguments
-Qun
Hi Dear Luigi,
I use your netmap pkt-gen for testing my applications and thanks you for
your great nice work.
I want to modify (if I can!) your pkt-gen such that I can insert timestamps
in udp packets in order to find delay of receiving packets (that forward
from my DUT).
ِDo you have any
On Mon, Jun 24, 2013 at 11:12 AM, Olivier Cochard-Labbé
wrote:
> Hi,
>
> I'm using netmap pkt-gen as a packet generator/receiver and it's
> working great for generating one-flow (one src/dst IP address).
> But I would like generate packets with multiples source&dest
Hi,
I'm using netmap pkt-gen as a packet generator/receiver and it's
working great for generating one-flow (one src/dst IP address).
But I would like generate packets with multiples source&destination IP
addresses.
pkt-gen support "range" IP and MAC address:
-d dst-ip
On Wed, Jan 9, 2013 at 5:50 PM, Olivier Cochard-Labbé
wrote:
>
> Now I reach to use it on -current and, following your advice, on 9.1 too.
> The patch (for 9.1-release) that I've used his here:
> http://gugus69.free.fr/freebsd/freebsd.netmap.patch
>
Hi,
I've just discovered that on i386 (no pro
On Wed, Jan 9, 2013 at 2:54 PM, Luigi Rizzo wrote:
> you need to add a "device netmap" option in your kernel config file in order
> to
> build the device drivers with the required changes.
"device netmap" was the forgotten part !
Now I reach to use it on -current and, following your advice, on
On Wed, Jan 9, 2013 at 5:21 AM, Olivier Cochard-Labbé wrote:
> On Wed, Jan 9, 2013 at 12:02 AM, Luigi Rizzo wrote:
>
> > not your mistake, on stable/9 i have not merged yet the
> > device driver changes.
> > Your best option is to copy sys/dev/netmap from HEAD,
> > and add the device-specific chu
On Wed, Jan 9, 2013 at 12:02 AM, Luigi Rizzo wrote:
> not your mistake, on stable/9 i have not merged yet the
> device driver changes.
> Your best option is to copy sys/dev/netmap from HEAD,
> and add the device-specific chunks also from HEAD
> into the various drivers (dev/e1000, dev/ixgbe, dev/
On Tue, Jan 08, 2013 at 11:39:10PM +0100, Olivier Cochard-Labb? wrote:
> Hi,
> I'm try to use netmap pkt-gen on real and virtual (virtualbox)
> hardware with FreeBSD 9.1.
> My setup is pretty simple:
>
> ( HOST1 em0:1.1.1.1 ) <--> ( em0:1.1.1.2 HOST2 )
>
>
Hi,
I'm try to use netmap pkt-gen on real and virtual (virtualbox)
hardware with FreeBSD 9.1.
My setup is pretty simple:
( HOST1 em0:1.1.1.1 ) <--> ( em0:1.1.1.2 HOST2 )
But I didn't reach to use pkt-gen (from tools/tools/netmap), I've got
errors (on both physical
70 matches
Mail list logo
