<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">pá 6. 2. 2026 v 15:02 odesílatel Thomas Monjalon <<a href="mailto:thomas@monjalon.net">thomas@monjalon.net</a>> napsal:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">04/02/2026 15:53, Stephen Hemminger:<br>
> On Tue, 3 Feb 2026 09:34:26 +0100<br>
> Lukáš Šišmiš <<a href="mailto:sismis@dyna-nic.com" target="_blank">sismis@dyna-nic.com</a>> wrote:<br>
> <br>
> > ><br>
> > > The kernel version of checkpatch complains here. The DPDK shell script<br>
> > > seems to be set to ignore this but.<br>
> > ><br>
> > > WARNING: break is not useful after a return<br>
> > > #15008: FILE: lib/flow_parser/rte_flow_parser.c:14763:<br>
> > > +               return cmd_flow_parsed(out);<br>
> > > +               break;<br>
> > ><br>
> > > Should I create a new patch set or just let it be at this moment?  <br>
> > Lukas<br>
> <br>
> <br>
> I am ok with it as is.<br>
<br>
Better to update.<br>
<br>
There are other warnings:<br>
<br>
WARNING:STRNCPY: Prefer strscpy, strscpy_pad, or __nonstring over strncpy - see: <a href="https://github.com/KSPP/linux/issues/90#13052" rel="noreferrer" target="_blank">https://github.com/KSPP/linux/issues/90<br>
#13052</a>: FILE: lib/flow_parser/rte_flow_parser.c:12825:<br>
+       strncpy(buf, str, len);<br>
<br>
and a lot of WARNING:LONG_LINE<br>
<br></blockquote><div>I can have a look after the decision.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
And on a more general note, I would have expected to ask the opinion<br>
of rte_flow maintainers, but they are not Cc'ed in these patches.<br></blockquote><div>I communicated primarily with Stephen, and will CC Ori too. Anyone else?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'm a bit skeptical about adding this outside of ethdev library<br>
which defines the flow API.<br></blockquote><div><br></div><div>CCing Ori to make a decision. I don't mind putting it directly into ethdev as well, I just thought the parser could be its own separate lib as it is just consuming strings and producing rte_flow structures. I can see the heavy ties to the flow library, though. Thomas, Stephen, what are your opinions?</div></div></div>