4 .. **Read this first.**
6 The text in the sections below explains how to update the release notes.
8 Use proper spelling, capitalization and punctuation in all sections.
10 Variable and config names should be quoted as fixed width text:
13 Build the docs and view the output file to ensure the changes are correct::
17 xdg-open build/doc/html/guides/rel_notes/release_17_11.html
23 .. This section should contain new features added in this release. Sample
26 * **Add a title in the past tense with a full stop.**
28 Add a short 1-2 sentence description in the past tense. The description
29 should be enough to allow someone scanning the release notes to
30 understand the new feature.
32 If the feature adds a lot of sub-features you can use a bullet list like
35 * Added feature foo to do something.
36 * Enhanced feature bar to do something else.
38 Refer to the previous release notes for examples.
40 This section is a comment. do not overwrite or remove it.
41 Also, make sure to start the actual text at the margin.
42 =========================================================
44 * **nfp: Added PF support.**
46 Previously Netronome's NFP PMD had just support for VFs. PF support is
47 just as a basic DPDK port and has no VF management yet.
49 PF support comes with firmware upload support which allows the PMD to
50 independently work from kernel netdev NFP drivers.
52 NFP 4000 devices are also now supported along with previous 6000 devices.
58 .. This section should contain bug fixes added to the relevant
59 sections. Sample format:
61 * **code/section Fixed issue in the past tense with a full stop.**
63 Add a short 1-2 sentence description of the resolved issue in the past
66 The title should contain the code/lib section like a commit message.
68 Add the entries in alphabetic order in the relevant sections below.
70 This section is a comment. do not overwrite or remove it.
71 Also, make sure to start the actual text at the margin.
72 =========================================================
78 * **Service core fails to call service callback due to atomic lock**
80 In a specific configuration of multi-thread unsafe services and service
81 cores, a service core previously did not correctly release the atomic lock
82 on the service. This would result in the cores polling the service, but it
83 looked like another thread was executing the service callback. The logic for
84 atomic locking of the services has been fixed and refactored for readability.
105 .. This section should contain new known issues in this release. Sample format:
107 * **Add title in present tense with full stop.**
109 Add a short 1-2 sentence description of the known issue in the present
110 tense. Add information on any known workarounds.
112 This section is a comment. do not overwrite or remove it.
113 Also, make sure to start the actual text at the margin.
114 =========================================================
120 .. This section should contain API changes. Sample format:
122 * Add a short 1-2 sentence description of the API change. Use fixed width
123 quotes for ``rte_function_names`` or ``rte_struct_names``. Use the past
126 This section is a comment. do not overwrite or remove it.
127 Also, make sure to start the actual text at the margin.
128 =========================================================
130 * **Service cores API updated for usability**
132 The service cores API has been changed, removing pointers from the API
133 where possible, instead using integer IDs to identify each service. This
134 simplifed application code, aids debugging, and provides better
135 encapsulation. A summary of the main changes made is as follows:
137 * Services identified by ID not by ``rte_service_spec`` pointer
138 * Reduced API surface by using ``set`` functions instead of enable/disable
139 * Reworked ``rte_service_register`` to provide the service ID to registrar
140 * Rework start and stop APIs into ``rte_service_runstate_set``
141 * Added API to set runstate of service implementation to indicate readyness
147 .. This section should contain ABI changes. Sample format:
149 * Add a short 1-2 sentence description of the ABI change that was announced
150 in the previous releases and made in this release. Use fixed width quotes
151 for ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
153 This section is a comment. do not overwrite or remove it.
154 Also, make sure to start the actual text at the margin.
155 =========================================================
159 Shared Library Versions
160 -----------------------
162 .. Update any library version updated in this release and prepend with a ``+``
166 + librte_cfgfile.so.2
169 This section is a comment. do not overwrite or remove it.
170 =========================================================
173 The libraries prepended with a plus sign were incremented in this version.
178 librte_bitratestats.so.1
181 librte_cryptodev.so.3
182 librte_distributor.so.1
192 librte_latencystats.so.1
204 librte_pmd_ixgbe.so.1
206 librte_pmd_vhost.so.1
220 .. This section should contain a list of platforms that were tested with this
225 * <vendor> platform with <vendor> <type of devices> combinations
230 * Other relevant details...
232 This section is a comment. do not overwrite or remove it.
233 Also, make sure to start the actual text at the margin.
234 =========================================================