Monitoring and Tuning the Linux Networking Stack: Receiving Data
blog.packagecloud.io
Monitoring and Tuning the Linux Networking Stack: Receiving Data
1–10 of 10 posts
Re: Monitoring and Tuning the Linux Networking Stack: Receiving Data
#2It is a bit hard to follow the listings as they don't use a monospaced font. A part from that, very detailed and useful article.
Re: Monitoring and Tuning the Linux Networking Stack: Receiving Data
#3It is a bit hard to follow the listings as they don't use a monospaced font. A part from that, very detailed and useful article.
Sorry about that! What browser/operating system? I suspect this is a missing font issue.
Re: Monitoring and Tuning the Linux Networking Stack: Receiving Data
#4While most of this can be found in the MAN pages, this is a nice synopsis to have on hand. Definitely going to bookmark this.
Re: Monitoring and Tuning the Linux Networking Stack: Receiving Data
#5It is a bit hard to follow the listings as they don't use a monospaced font. A part from that, very detailed and useful article.
Sorry about that! What browser/operating system? I suspect this is a missing font issue.
I think I see the same thing on Chrome/Linux. If I comment out the `font-family: monaco` rule in the `article.type-system-sans code` CSS rule, then a monospace font is used and makes things much more readable.
Re: Monitoring and Tuning the Linux Networking Stack: Receiving Data
#6> There is, unfortunately, no easy way out.
Disagree. BSD.
Re: Monitoring and Tuning the Linux Networking Stack: Receiving Data
#7Earlier quoted context omitted.
Sorry about that! What browser/operating system? I suspect this is a missing font issue.
I think I see the same thing on Chrome/Linux. If I comment out the `font-family: monaco` rule in the `article.type-system-sans code` CSS rule, then a monospace font is used and makes things much more readable.
Just deployed a fix, thanks for the bug report!
Re: Monitoring and Tuning the Linux Networking Stack: Receiving Data
#8A nice overview; thanks for sharing it!
I don't think that your claim that GRO is "a software implementation of a hardware optimization that is known as Large Receive Offloading (LRO)" is correct, though. GRO effectively replaces LRO [1]; it has fewer limitations (it works with non-TCP traffic and with bridging [2], for example). Drivers need to support it, but they are free to take advantage of hardware offloading/acceleration, and many do (including e.g. the ixgbe driver [3]).
----
[1] In terms of function, and in the sense that LRO could be removed if the drivers that were using LRO were updated to use GRO instead.
[2] Relevant bug: https://bugzilla.redhat.com/show_bug.cgi?id=772317
[3] Which actually supports both LRO and GRO; if I recall, in older versions, bad things(tm) would sometimes happen if you had both enabled at the same time (whereas now the LRO setting is ignored if GRO is enabled).
Re: Monitoring and Tuning the Linux Networking Stack: Receiving Data
#9> There is, unfortunately, no easy way out. Disagree. BSD.
That's a tough pill to swallow for many
Re: Monitoring and Tuning the Linux Networking Stack: Receiving Data
#10> There is, unfortunately, no easy way out. Disagree. BSD.
There's also kernel bypass setups which seem to be common when crazy performance is required.