[adding ovs-dev back]
On Fri, Sep 09, 2011 at 01:23:58PM -0700, Ben Pfaff wrote: > On Fri, Sep 09, 2011 at 01:14:44PM -0700, Ethan Jackson wrote: > > > I'd be tempted to say that mpids must be in either range [1, 8191] or > > > [UINT16_MAX + 1, UINT64_MAX], which would allow cfm_is_valid_mpid() to > > > be valid even for extended mpids, but I'll leave that up to you. > > > > When configuring this by hand it's fairly convenient to be able to set > > the mpid to low values like 1 or 2. I regularly assign 1 to eth1 2 to > > eth2 etc. I don't really see a good reason to restrict that in > > extended mode. > > 1 and 2 are both in the range [1, 8191], so they would be allowed. > > The only disallowed values would be 0 and [8192, UINT16_MAX]. > > > > When extended mode is enabled, the "normal" mpid is generated with a > > > hash, but I don't see anything that ensures that the hash value is in > > > the range [1, 8191]. > > > > I did this on purpose but perhaps my reasoning was bad. I haven't > > found a good reason for the restriction to the range 1 to 8191. Since > > we are running in extended mode I felt at liberty to break the > > protocol, especially since the hash is only useful for differentiating > > CCMs in tcpdump. I'm worried about collisions in this field making > > tcpdump output confusing, so I wanted to use as many bits as possible. > > That said, one could make an argument for being standards compliant in > > this field as well. Do you have a strong opinion? > > No, I don't. I assumed it was an oversight, but it sounds like you > thought it through. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
