> > > > Should we have a command line option to configure the forwarding rules > > in the application (2)? I think yes. > > Should we implement an application logic to automatically create the > > best forwarding rules (1)? It would be nice, but anyway, I think we > > need manual config (2) as a fallback. > > > > > > > Thoughts? If you think, there is a rework needed in eal then could > > > you enumerate the items for the rework. > > > > Sorry I don't have time to describe dive into EAL probing and > > enumerate the items to rework. > > The most important issues I remind are: > > - white/blacklist policy is a mess and should be done in a higher > > layer > > - devargs syntax should allow generic matching (thanks to > > class awareness and generic syntax) > > > > Starting from these 2 items, we could imagine a generic path to > > disable automatic probing, but I think the l2fwd logic should not rely > > on probing order anyway. > > + Bruce as l2fwd maintainer. > > Since in any case, l2fwd needs to be updated, We will focus on l2fwd change > for v20.05 and leaving the fate of this patch to EAL maintainers. > Let us know, Are we are OK with below change in l2fwd as > - Introduce an array-based port lookup table instead of hardcoding to xor > based > lookup. > - if no argument specified fill dest port as xor of source > - If argument is specified override the lookup table with a user-specified > destination port.
I think, this thread can be closed here. L2fwd change sent as different patch. Please review if it is for interest. http://patches.dpdk.org/patch/67722/ > > > > > > >
