https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
Andrew Gallatin changed:
What|Removed |Added
CC||galla...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
Cheng Cui changed:
What|Removed |Added
CC||c...@freebsd.org
--- Comment #25 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
--- Comment #24 from Kevin Bowling ---
(In reply to pascal.guitierrez from comment #23)
Thanks for reporting back. That is very interesting.
There are two possibilities that come to mind 1) the RACK stack is correctly
identifying the loss
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
--- Comment #23 from pascal.guitier...@gmail.com ---
(In reply to Kevin Bowling from comment #21)
(In reply to Kevin Bowling from comment #22)
Interesting, thanks for that.
I tried changing dev.igb.0.iflib.override_ntxqs=4096 but to no eff
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
--- Comment #22 from Kevin Bowling ---
(In reply to Kevin Bowling from comment #21)
Thinking back a bit harder one thing that might help workaround this is to
increase the number of transmit descriptors.. try something like this in
/boot/lo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
--- Comment #21 from Kevin Bowling ---
(In reply to pascal.guitierrez from comment #20)
> Do you know if this is expected behaviour or is it a problem?
Caveat it has been a long time since I have been line-rating large numbers of
FreeBSD sy
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
--- Comment #20 from pascal.guitier...@gmail.com ---
(In reply to Kevin Bowling from comment #19)
Thanks Kevin, yes you are right, repeating the test gets to a state where
interrupts are processed on a single core and packet drops occur:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
--- Comment #19 from Kevin Bowling ---
(In reply to pascal.guitierrez from comment #18)
if you watch 'systat -vmstat', does the zero drop case happen when all the igb
interrupts are on one core, or two cores? If you rerun the -P2 test seve
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
--- Comment #18 from pascal.guitier...@gmail.com ---
(In reply to Aleksandr Fedorov from comment #17)
currently at default of dev.igb.0.fc=3
changing it has no apparent effect.
however what i notice is that re-running the test results in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
Aleksandr Fedorov changed:
What|Removed |Added
CC||afedo...@freebsd.org
--- Comme
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
--- Comment #16 from pascal.guitier...@gmail.com ---
(In reply to Kevin Bowling from comment #15)
Thanks Kevin
no bridge filtering is enabled (sysctl net.link.bridge):
net.link.bridge.ipfw: 0
net.link.bridge.log_mac_flap: 1
net.link.bridg
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
Kevin Bowling changed:
What|Removed |Added
CC||kbowl...@freebsd.org
--- Comment #
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
--- Comment #14 from pascal.guitier...@gmail.com ---
(In reply to pascal.guitierrez from comment #13)
.. and yes I repeated the tests with those flags and i'm still seeing packet
drops
--
You are receiving this mail because:
You are the a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
--- Comment #13 from pascal.guitier...@gmail.com ---
(In reply to erwin.freebsd-bugzilla from comment #12)
thanks for your reply.
can you run the same iperf3 tests without and with a bridge involved? In my
testing, there are no dropped pac
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
erwin.freebsd-bugzi...@bk3.nl changed:
What|Removed |Added
CC||erwin.freebsd-bugzil
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
--- Comment #11 from fatal...@gmail.com ---
(In reply to fatalnix from comment #10)
Ugh. Actually, it does increase with the thread increase. I was looking at the
wrong number heheh. So, this might be sometghing that's load related somehow.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
--- Comment #10 from fatal...@gmail.com ---
I have upgraded to 14.1-release-p2 and I am now able to reproduce this issue
using the same tests.
I did a few different tests, ensuring a solid 950~ Mbit/s link during my iperf3
tests. Each of th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
--- Comment #9 from pascal.guitier...@gmail.com ---
(In reply to Mark Johnston from comment #8)
Thanks Mark, i'm using iperf3 -s on the server and iperf3 -P4 -c 192.168.0.5 -t
60 on the client, which i believe does create multiple flows:
t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
Mark Johnston changed:
What|Removed |Added
CC||ma...@freebsd.org
Stat
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
--- Comment #7 from pascal.guitier...@gmail.com ---
(In reply to fatalnix from comment #6)
it's my understanding that adding the device to the bridge switches off the NIC
offloading features automatically.
i'm getting 942Mb/sec and interes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
--- Comment #6 from fatal...@gmail.com ---
(In reply to fatalnix from comment #5)
As a fix for the previous message where I asked what happens if you disable
offloading, I meant to say, "What happens if you do not disable offloading".
--
Y
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
fatal...@gmail.com changed:
What|Removed |Added
CC||fatal...@gmail.com
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
--- Comment #4 from pascal.guitier...@gmail.com ---
(In reply to Zhenlei Huang from comment #3)
Here's the output from sysctl dev.igb.0.iflib | grep r_drops
dev.igb.0.iflib.txq3.r_drops: 37
dev.igb.0.iflib.txq2.r_drops: 37
dev.igb.0.iflib.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
--- Comment #3 from Zhenlei Huang ---
(In reply to pascal.guitierrez from comment #2)
Emm, igb(4) has been converted to use iflib(4). It seems that the iflib
implementation does not report statistics of output dropped packets (
IFCOUNTER_OQ
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
--- Comment #2 from pascal.guitier...@gmail.com ---
(In reply to Zhenlei Huang from comment #1)
Thanks for your response.
Just ran the tests again.
There are no dropped packets detected even though the Oerr count is increasing,
see below f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
--- Comment #1 from Zhenlei Huang ---
(In reply to pascal.guitierrez from comment #0)
The if_bridge(4) promote underlaying errors from bridge members,
```
2108 if ((err = dst_ifp->if_transmit(dst_ifp, m))) {
2109
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
27 matches
Mail list logo