Hi Thomas, > 2016-03-08 17:04, Yuanhan Liu: > > On Tue, Mar 08, 2016 at 10:49:30AM +0200, Panu Matilainen wrote: > > > On 03/07/2016 03:13 PM, Yuanhan Liu wrote: > > > >To me, maybe you could base the SINGLE_FILE_SEGMENTS option, and > > > >add another option, say --no-sort (I confess this name sucks, but > > > >you get my point). With that, we could make sure to create as least > > > >huge page files as possible, to fit your case. > > > > > > Note that SINGLE_FILE_SEGMENTS is a nasty hack that only the > IVSHMEM > > > config uses, getting rid of it (by replacing with a runtime switch) would > > > be > great. > > > > Can't agree more. > > +1 > > > BTW, FYI, Jianfeng and I had a private talk, and we came to agree that > > it might be better to handle it outside the normal huge page init > > stage, just like this patch does, but adding the support of multiple > > huge page sizes. Let's not add more messy code there. > > > > --yliu > > > > > OTOH IVSHMEM itself seems to have fallen out of the fashion since > > > the memnic driver is unmaintained and broken since dpdk 2.0... > > > CC'ing the IVSHMEM maintainer in case he has thoughts on this. > > The ivshmem config was not used for memnic which was using ivshmem only > for data path. > CONFIG_RTE_LIBRTE_IVSHMEM and > CONFIG_RTE_EAL_SINGLE_FILE_SEGMENTS are more about full memory > sharing. > I have the feeling it could be dropped. > It there are some users, I'd like to see a justification and a rework to > remove > these build options.
Just to add my opinion to it - if there are no users for both of these, I'd like for those to be removed as well. Less maintenance is always better than more maintenance, especially for things that no one uses :) Thanks, Anatoly
