Next step in consolidating the IP fragment management
Status from this message: Applied, but if we ever implement dynamically sized frag
Get series with b4
b4 am [email protected]Versions newest first
Patches in v1 Applied
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/7 | Omit double hash calculations in xxx_frag_internnet/ net/ | +9 | 1 reply | |
| 2/7 | Consolidate xxx_frag_interninclude/ include/ net/ +3 more | +82 | 1 reply | |
| 3/7 | Consolidate xxx_frag_alloc()include/ net/ net/ +2 more | +41 | 1 reply | |
| 4/7 | Consolidate xxx_frag_create()include/ include/ net/ +3 more | +88 | 1 reply | |
| 5/7 | Consolidate xxx_find() in fragment managementinclude/ include/ net/ +3 more | +73 | 1 reply | |
| 6/7 | Remove no longer needed ->equal callbackinclude/ include/ net/ +3 more | +3 | 1 reply | |
| 7/7 | Consolidate frag queues freeingnet/ net/ net/ +1 more | +5 | 1 reply |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/7] Next step in consolidating the IP fragment management
This set concerns the xxx_find() routine only. This one is used to obtain the fragment queue depending on some criteria, and this can be consolidated.
The consolidation goes step-by-step, consolidating one sub-routine at a time, so some functions, exports and callbacks that are introduced in patches are temporary and are removed in some subsequent patch.
Signed-off-by Pavel Emelyanov <[email protected]>