Hi,
On 09/02/2022 13:54, Bruce Richardson wrote:
On Wed, Feb 09, 2022 at 12:00:40PM +0000, Ananyev, Konstantin wrote:
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*.
I think it really depends on whether you are planning on implementing a
general config file for the application, or whether the file(s) will only
contain the LPM/FIB routing entries. If the plan is reading just the
routing entries from file, then I definitely think that it might be
something that would be generally useful inside the library itself.
If it's a more general config file with other app settings in it, then an
examples-only parse function/file would make more sense.
I vote for this code to be in examples where we can control the file
format with LPM/FIB entries.
I don't think it's a good idea to move this API to the data plane
library. I think it will only be used in our examples because dpdk users
will have their own formats for routing information.
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.
Konstantin
--
Regards,
Vladimir
