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. > 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
