On Mon, Feb 6, 2012 at 8:06 PM, Pravin Shelar <[email protected]> wrote: > On Mon, Feb 6, 2012 at 6:18 PM, Jesse Gross <[email protected]> wrote: >> On Thu, Feb 2, 2012 at 6:58 AM, Pravin B Shelar <[email protected]> wrote: >>> diff --git a/datapath/datapath.h b/datapath/datapath.h >>> index b012a76..05f6de8 100644 >>> --- a/datapath/datapath.h >>> +++ b/datapath/datapath.h >>> @@ -34,7 +34,10 @@ >>> #include "vlan.h" >>> #include "vport.h" >>> >>> -#define DP_MAX_PORTS 1024 >>> +/* Flex array limit. */ >>> +#define DP_MAX_PORTS (FLEX_ARRAY_ELEMENTS_PER_PART(sizeof(struct vport *)) >>> * \ >>> + FLEX_ARRAY_NR_BASE_PTRS) >> >> In most situations the number of ports is actually small enough that >> it's possible to fit them all in the single page version of flex >> array. It would be nice if we could take advantage of that, although >> that depends on what the other changes look like since we'll need to >> be able to pivot from the single page to multiple pages safely if the >> need arises. >> > Are you saying we shld do expansion like flow-table for vport table ?
Originally, yes, I was thinking that it would be nice to more gracefully handle the common case. However, I realized that this might not go far enough. OVS userspace tries not to recycle port numbers, which means that even for a constant number of VMs on a machine if there is some churn (maybe from migrations) over time we'll keep on expanding the table and allocating more memory that's not really used. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
