[ovs-dev] [PATCH RFC 0/1] dpif-netdev: Make EMC Size Configurable

[Ben Pfaff]

On Tue, Apr 21, 2015 at 07:21:36PM +0100, Daniele Di Proietto wrote:
> 
> > On 21 Apr 2015, at 17:01, Loftus, Ciara <ciara.loftus at intel.com> wrote:
> > 
> > 
> > 
> >> -----Original Message-----
> >> From: Ben Pfaff [mailto:blp at nicira.com]
> >> Sent: Tuesday, April 21, 2015 4:08 PM
> >> To: Loftus, Ciara
> >> Cc: dev at openvswitch.org
> >> Subject: Re: [ovs-dev] [PATCH RFC 0/1] dpif-netdev: Make EMC Size
> >> Configurable
> >> 
> >> On Tue, Apr 21, 2015 at 01:47:12PM +0100, Ciara Loftus wrote:
> >>> This patch allows the user to specify the number of Exact Match Cache
> >>> entries they wish to have available for their instance of the vswitch.
> >>> This is a achieved by means of a 'configure' flag.
> >>> 
> >>> At the moment, the default number of EMC entries is 1024, for which
> >>> the switch should perform optimally up to this number of flows.
> >>> However, if the user expects say roughly 2000 flows of traffic, an EMC
> >>> with 2048 entries will perform better, allbeit with a larger demand on
> >>> memory and time spent flushing the cache. If these requirements are
> >>> acceptable to the user, they may choose to allocate 2048 entries like so,
> >>> and in turn receive improved performance for their specific use case:
> >>> 
> >>> './configure --with-emcsize=11'
> >>> 
> >>> The number of entries is calculated as 2^11 = 2048.
> >> 
> >> configure flags are really inconvenient.  Is there a reason that this
> >> can't be made configurable at runtime?  It would be better yet if the
> >> EMC size could automatically adjust itself.
> > 
> > Thanks for the feedback. The implementation is naturally more complex for a runtime configurable but I think achievable - I'll look into it.
> 
> Making it configurable at runtime is an option, but if that turns out
> to be too complex I think we could just make it bigger.
> 
> Each entry takes 176 bytes.  We could, for example, reserve 16K
> entries: that would take only 2.8 MB per core and (IMHO) it's
> totally reasonable to reserve that memory in userspace.
> 
> What do you guys think?
> I'm CCing Ethan, as he might be interested in this too.

I'm happy to let you guys figure this out, I just think that
configure-time options are undesirable in general.  I'd probably make
the same suggestion for any new configure option.