Discussion:
[Bug 210901] em0 stores packets somewhere and lets them out slowly under load.
b***@freebsd.org
4 years ago
Permalink
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210901

Kevin Bowling <***@freebsd.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|New |Closed
Resolution|--- |Not Enough Information

--- Comment #4 from Kevin Bowling <***@freebsd.org> ---
I suspect this will work a lot better on newer releases. If you have time to
retest please let us know.
--
You are receiving this mail because:
You are the assignee for the bug.
b***@freebsd.org
4 years ago
Permalink
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210901

--- Comment #5 from ***@eicat.ca ---
Have things changed significantly? I abandoned jumbo packets because they were
more problems than they were worth. With Covid, my wife is working at home now
--- so the server affects more than one person if I get it to missbehave. I
can't even logically delegate this to a VM ... as the outer system would need
jumbo packets. Are pages even 4k? still? So much information I don't have.

This wasn't difficult to trigger --- and if I'm the only one up for testing, I
suppose I can make time --- but someone with a lab of systems might be a better
choice.

The system in question had 32G ram then. It has 128G now.
--
You are receiving this mail because:
You are the assignee for the bug.
b***@freebsd.org
4 years ago
Permalink
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210901

--- Comment #6 from Kevin Bowling <***@freebsd.org> ---
(In reply to dgilbert from comment #5)
Yes, the intel driver was substantially rewritten, so it would be necessary to
retest to continue, and will need some active data collection on top of that
once the symptoms are produced.

It's a big topic to discuss jumbo frames in general, I would agree with your
assessment to not use them. I have secondary concern you might have run into
memory fragmentation issues, the way larger frames are handled is sub-optimal
in FreeBSD. Although that is not a driver bug so it still makes sense to close
this PR out.
--
You are receiving this mail because:
You are the assignee for the bug.
b***@freebsd.org
4 years ago
Permalink
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210901

Chris Hutchinson <***@bsdforge.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@bsdforge.com

--- Comment #7 from Chris Hutchinson <***@bsdforge.com> ---
This sound alot like an interrupt problem to me. I'm
NOT suggesting that a newer FreeBSD/driver version
won't help mitigate this. Just that it sounds to me
like an interrupt "thing" -- especially when I see:
em0: Using an MSI interrupt

If you add
boot_verbose="YES"
to loader.conf(5). Do you see a line with Quirks
in it related to your card? I would expect to see
MSI-X associated with your (em) card.

HTH

--Chris
--
You are receiving this mail because:
You are the assignee for the bug.
b***@freebsd.org
4 years ago
Permalink
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210901

--- Comment #8 from Kevin Bowling <***@freebsd.org> ---
(In reply to Chris Hutchinson from comment #7)
There is an MSI errata on this particular chip, see issue 63
https://raw.githubusercontent.com/tpn/pdfs/master/Intel%20Ethernet%20Controller%2082571EB%2C%2082572EI%2C%2082571GB%2C%2082571GI%20-%20Specification%20Update%20-%20Rev%206.8%20Nov%202014.pdf

I could hack something together for you right now to force a legacy interrupt
if you want to investigate that. But first we need to see if the problem still
exists, moving our effort to 12 or 13 to be useful.
--
You are receiving this mail because:
You are the assignee for the bug.
b***@freebsd.org
4 years ago
Permalink
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210901

--- Comment #9 from ***@eicat.ca ---
to be clear, this didn't seem to be interrupt related at all. it was a
resource starvation caused by memory fragmentation and the bone-headed way we
handle 9k jumbo frames. The whole problem would boil down to having a scarce
few 9k jumbo frame buffers servicing all the packets coming in (and the few
large ones going out).

The system now has an mlxen driver card in it. Even more reason to prefer
jumbo frames with 10GE, but, again... I haven't even bothered as it appeared
that the jumbo frames were the issue, not the interrupts.

So... it's very possible that this ticket should be closed --- but only if
another regarding jumbo frames > 4k is opened.
--
You are receiving this mail because:
You are the assignee for the bug.
b***@freebsd.org
4 years ago
Permalink
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210901

Kevin Bowling <***@freebsd.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Resolution|Not Enough Information |DUPLICATE

--- Comment #10 from Kevin Bowling <***@freebsd.org> ---


*** This bug has been marked as a duplicate of bug 255070 ***
--
You are receiving this mail because:
You are the assignee for the bug.
b***@freebsd.org
4 years ago
Permalink
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210901

--- Comment #11 from Kevin Bowling <***@freebsd.org> ---
(In reply to dgilbert from comment #9)
I agree with your assessment, I opened a tracking bug up for the general issue
of jumbos.
--
You are receiving this mail because:
You are the assignee for the bug.
Loading...