[ovs-dev] [ofproto tests 03/29] ofp-util: Use a counter for transaction IDs instead of a random number.

Ben Pfaff blp at nicira.com
Thu Nov 18 00:56:24 UTC 2010


That's the next commit.

On Wed, Nov 17, 2010 at 04:54:47PM -0800, Justin Pettit wrote:
> Do you think it's worth doing an htonl() on the xid, so it's obviously
> consecutive on the wire?
> 
> --Justin
> 
> 
> On Nov 16, 2010, at 11:20 AM, Ben Pfaff wrote:
> 
> > I don't know of any reason why the transaction id should be random.  Using
> > consecutive ids means that there is no chance that two messages sent around
> > the same time will have the same transaction ID, which is probabilitically
> > possible with random IDs.
> > ---
> > lib/ofp-util.c |    8 ++++----
> > 1 files changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/lib/ofp-util.c b/lib/ofp-util.c
> > index d7bc0ee..8a9a8ec 100644
> > --- a/lib/ofp-util.c
> > +++ b/lib/ofp-util.c
> > @@ -32,12 +32,12 @@ VLOG_DEFINE_THIS_MODULE(ofp_util);
> >  * in the peer and so there's not much point in showing a lot of them. */
> > static struct vlog_rate_limit bad_ofmsg_rl = VLOG_RATE_LIMIT_INIT(1, 5);
> > 
> > -/* XXX we should really use consecutive xids to avoid probabilistic
> > - * failures. */
> > -static inline uint32_t
> > +/* Returns a transaction ID to use for an outgoing OpenFlow message. */
> > +static uint32_t
> > alloc_xid(void)
> > {
> > -    return random_uint32();
> > +    static uint32_t next_xid = 1;
> > +    return next_xid++;
> > }
> > 
> > /* Allocates and stores in '*bufferp' a new ofpbuf with a size of
> > -- 
> > 1.7.1
> > 
> > 
> > _______________________________________________
> > dev mailing list
> > dev at openvswitch.org
> > http://openvswitch.org/mailman/listinfo/dev_openvswitch.org
> 




More information about the dev mailing list