Thread (17 messages) flat view 17 messages, 5 authors, 2017-10-04

Re: [PATCH v4 net-next 0/8] flow_dissector: Protocol specific flow dissector offload

From: Jiri Pirko <jiri@resnulli.us>
Date: 2017-10-03 07:46:34

Fri, Sep 29, 2017 at 07:59:35PM CEST, tom@herbertland.com wrote:
On Fri, Sep 29, 2017 at 10:42 AM, David Miller [off-list ref] wrote:
quoted
From: Tom Herbert <redacted>
Date: Fri, 29 Sep 2017 08:48:55 -0700
quoted
The flow_dissector interface is not a uAPI.
That's not true, insofar as cls_flower.c uses the flow_dissector
therefore if you change the flow_dissector in certain ways then
cls_flower.c might have it's behavior changed and that is in fact UAPI
facing.
Then I would suggest adding another flag like FLOW_DISSECTOR_F_FLOWER
and when anyone puts new code into flow_dissector they can wrap it
with "if !(flags & FLOW_DISSECTOR_F_FLOWER)". If the flower uAPI is
subsequently update then the conditional can be removed. This way
flower can support maintain its APIs, but we can still still extend
and improve flow_dissector for othersuse cases.
This is not flower-specific problem. Flow_dissector is a servant of many.
As such, it is instructed what should it do. If you want to
change the way inner headers are parsed, you should either:
1) change the callers so they are behaving the same as before
2) make the flow_dissection change optional so the caller can say if he
   wants original or new behaviour.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help