[PATCH] doc/design: minor cleanus

[Stephen Hemminger <stephen@networkplumber.org>]

Minor fixes to previous edit:
 1. remove blank line at end of file, causes git complaint
 2. fix minor typo (UTF-8?)
 3. break long lines, although rst doesn't care it is nicer
    for future editors to keep to 100 characters or less.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
Depends-on: patch-141466 ("doc: reword design section in contributors guideline")

 doc/guides/contributing/design.rst | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/doc/guides/contributing/design.rst b/doc/guides/contributing/design.rst
index 3d1f5aeb91..77c4d3d823 100644
--- a/doc/guides/contributing/design.rst
+++ b/doc/guides/contributing/design.rst
@@ -63,9 +63,16 @@ The following macro options can be used:
 Mbuf features
 -------------
 
-A designated area in mbuf stores "dynamically" registered fields and flags. It is the default choice for accommodating new features. The "dynamic" area consumes the remaining space in the mbuf, indicating that it's being efficiently utilized. However, the ``rte_mbuf`` structure must be kept small (128 bytes).
+A designated area in mbuf stores "dynamically" registered fields and flags. It is the default choice
+for accommodating new features. The "dynamic" area consumes the remaining space in the mbuf,
+indicating that it's being efficiently utilized. However, the ``rte_mbuf`` structure must be kept
+small (128 bytes).
 
-As more features are added, the space for existinG=g "static" fields (fields that are allocated statically) may need to be reconsidered and possibly converted to "dynamic" allocation. Adding a new static field or flag should be an exception. It must meet specific criteria including widespread usage, performance impact, and size considerations. Before adding a new static feature, it must be justified by its necessity and its impact on the system's efficiency.
+As more features are added, the space for existing "static" fields (fields that are allocated
+statically) may need to be reconsidered and possibly converted to "dynamic" allocation. Adding a new
+static field or flag should be an exception. It must meet specific criteria including widespread
+usage, performance impact, and size considerations. Before adding a new static feature, it must be
+justified by its necessity and its impact on the system's efficiency.
 
 
 Runtime Information - Logging, Tracing and Telemetry
@@ -134,7 +141,8 @@ Mechanism to allow the application to turn library statistics on and off
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Having runtime support for enabling/disabling library statistics is recommended
-as build-time options should be avoided. However, if build-time options are used, as in the table library, the options can be set using c_args.
+as build-time options should be avoided. However, if build-time options are used,
+as in the table library, the options can be set using c_args.
 When this flag is set, all the counters supported by the current library are
 collected for all the instances of every object type provided by the library.
 When this flag is cleared, none of the counters supported by the current library
@@ -230,4 +238,3 @@ testing and prototyping purposes while the kernel work is ongoing. It should
 also be marked with an "EXPERIMENTAL" tag. If the functionality isn't
 upstreamable, then a case can be made to maintain the PF functionality in DPDK
 without the EXPERIMENTAL tag.
-
-- 
2.43.0