[PATCH v10 3/6] flow_parser: add shared parser library

[Lukáš Šišmiš]

pá 6. 2. 2026 v 15:02 odesílatel Thomas Monjalon <thomas at monjalon.net>
napsal:

> 04/02/2026 15:53, Stephen Hemminger:
> > On Tue, 3 Feb 2026 09:34:26 +0100
> > Lukáš Šišmiš <sismis at dyna-nic.com> wrote:
> >
> > > >
> > > > The kernel version of checkpatch complains here. The DPDK shell
> script
> > > > seems to be set to ignore this but.
> > > >
> > > > WARNING: break is not useful after a return
> > > > #15008: FILE: lib/flow_parser/rte_flow_parser.c:14763:
> > > > +               return cmd_flow_parsed(out);
> > > > +               break;
> > > >
> > > > Should I create a new patch set or just let it be at this moment?
> > > Lukas
> >
> >
> > I am ok with it as is.
>
> Better to update.
>
> There are other warnings:
>
> WARNING:STRNCPY: Prefer strscpy, strscpy_pad, or __nonstring over strncpy
> - see: https://github.com/KSPP/linux/issues/90
> #13052 <https://github.com/KSPP/linux/issues/90#13052>: FILE:
> lib/flow_parser/rte_flow_parser.c:12825:
> +       strncpy(buf, str, len);
>
> and a lot of WARNING:LONG_LINE
>
> I can have a look after the decision.

>
> And on a more general note, I would have expected to ask the opinion
> of rte_flow maintainers, but they are not Cc'ed in these patches.
>
I communicated primarily with Stephen, and will CC Ori too. Anyone else?


> I'm a bit skeptical about adding this outside of ethdev library
> which defines the flow API.
>

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/dev/attachments/20260206/72d294ee/attachment.htm>