> >
> > > > > > >> Or have a generic library for reading LPM entries. L3fwd is
> > > > > > >> supposed
> > > > > > >> to be as small as possible (it no longer is), and the real work
> > > > > > >> should
> > > > > > >> be done by libraries to make it easier to build other
> > > > > > >> applications.
> > > > > > >
> > > > > > > I never heard users ask about such thing,
> > > > > > > but if there is a demand for that, then I suppose it could be
> > > > > > > considered.
> > > > > > > CC-ing LPM/FIB maintainers to comment.
> > > > > > > Though I believe it should be a subject of separate patch and
> > > > > > > discussion
> > > > > > > (I think many questions will arise - what format should be, how
> > > > > > > to support
> > > > > > > different types of user-data, to make it generic enough, etc.).
> > > > > >
> > > > > > Agree, it is very application specific, so it could be really
> > > > > > difficult
> > > > > > to make it generic.
> > > > >
> > > > > But several other also have LPM tables, so why not have common code
> > > > > for other applications.
> > > > >
> > > > > examples/l3fwd-power/main.c
> > > > > examples/ipsec-secgw/rt.c
> > > > > examples/ip_fragmentation/main.c
> > > > > examples/l3fwd/l3fwd_lpm.c
> > > > > examples/ip_reassembly/main.c
> > > >
> > > > Ah yes, that's good point.
> > > > All these examples (except ipsec-secgw) started as l3fwd clones,
> > > > so all of them have hard-coded LPM (and EM) tables too.
> > > > Yes it would be good thing to address that problem too,
> > > > and have some common code (and common routes file format) for all of
> > > > them.
> > > > I don't know is that a good idea to introduce parse file function in
> > > > LPM/FIB library
> > > > itself, might be better to have something like
> > > > examples/common/lpm_parse*.
> > > > Anyway, this is an extra effort, and I think no-one has time for it in
> > > > 22.03 timeframe.
> > > > My suggestion would be for 22.03 go ahead with current l3fwd patches,
> > > > then later we can consider to make it common and update other examples.
> > >
> > > I don't think this patch is urgent.
> > > I suggest taking time to have common code for all examples
> > > and target a merge in DPDK 22.07.
> >
> > Well, yes, from one perspective it not really a critical one,
> > we do live with hard-coded routes inside l3fwd for nearly 10 year by now.
> > Though l3fwd is one of mostly used examples inside DPDK and
> > it is quite a pain to patch/rebuild it each time someone needs to run
> > l3fwd with a different routing table.
> > Merging this patch will allow people to use l3fwd for more realistic test
> > scenarios in a painless manner.
> > So I believe this patch is really helpful and should be beneficial for the
> > whole community.
> > Looking from that perspective, I don't see why it has to be "all or
> > nothing" attitude here.
> > Why we can't move one step at a time instead?
> > That would allow to split and effort in terms of
> > development/testing/upstreaming/etc.
>
> When a feature is merged, there is less incentives to rework.
> That's why, when a feature is not urgent,
> it is better to wait for the complete work.
That's true till some extent, though from other side
even without further rework that patch improves situation
from what we have right now.
So I don't see any harm here.