Re: [PATCH 1/3] doc: networking: prepare scaling document for conversion into RST
From: Jonathan Corbet <corbet@lwn.net>
Date: 2019-01-16 22:03:11
Also in:
linux-doc, lkml
On Wed, 9 Jan 2019 20:57:22 +0100 Otto Sabart [off-list ref] wrote:
Add markups which are necessary for successful conversion into reStructuredText. There are no semantic changes. Signed-off-by: Otto Sabart <redacted>
This seems generally good, except:
quoted hunk ↗ jump to hunk
Documentation/networking/scaling.txt | 131 +++++++++++++++++---------- 1 file changed, 85 insertions(+), 46 deletions(-)diff --git a/Documentation/networking/scaling.txt b/Documentation/networking/scaling.txt index b7056a8a0540..0ce13ed103bd 100644 --- a/Documentation/networking/scaling.txt +++ b/Documentation/networking/scaling.txt@@ -1,4 +1,8 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================================== Scaling in the Linux Networking Stack +===================================== Introduction@@ -10,11 +14,11 @@ multi-processor systems. The following technologies are described: - RSS: Receive Side Scaling - RPS: Receive Packet Steering - RFS: Receive Flow Steering - Accelerated Receive Flow Steering - XPS: Transmit Packet Steering +- RSS: Receive Side Scaling +- RPS: Receive Packet Steering +- RFS: Receive Flow Steering +- Accelerated Receive Flow Steering +- XPS: Transmit Packet Steering RSS: Receive Side Scaling@@ -45,7 +49,9 @@ programmable filters. For example, webserver bound TCP port 80 packets can be directed to their own receive queue. Such “n-tuple” filters can be configured from ethtool (--config-ntuple). -==== RSS Configuration + +RSS Configuration +`````````````````
The use of the heading levels is kind of strange; I'm not really sure why you did it that way? I'd rather this adhered to our normal hierarchy, so it should be: RSS Configuration ----------------- All of the other bottom-level headings should be as well. Fix that up, please, and I can take these. The whole series can also be squashed into a single patch (though I don't feel really strongly about that either way). Thanks, jon