On Sun, Sep 28, 2014 at 03:23:44PM -0700, Venkatesan, Venky wrote: > Keith, > > On 9/28/2014 11:04 AM, Wiles, Roger Keith wrote: > >I am also looking at the bulk dequeue routines, which the ring can be fixed > >or variable. On fixed < 0 on error is returned and 0 if successful. On a > >variable ring < 0 on error or n on success, but I think n can be zero in the > >variable case, correct? > > > >If these are true then why not have the routines return < 0 on error and >= > >0 on success. Which means a dequeue from a fixed ring would return only > >?requested size n? or < 0 if you error off the 0 case. The 0 case could be > >OK, if you allow zero to be return on a empty ring for the fixed ring case. > > > >Does this make sense to anyone? > It won't make sense unless you're aware of the history behind these > functions. The original functions that were implemented for the ring were > only the bulk functions (i.e. FIXED). They would return exactly the number > of items requested for dequeue (0 if success, negative if error), and not > return any if the required number were not available. > > The burst (i.e. VARIABLE) functions came in much later (think it was r1.3 > where we introduced them), and by that time, there were already quite a > number of deployments of DPDK in the field using the legacy ring functions. > Therefore we made the decision to keep the legacy behavior intact & not > impacting deployed code - and merging the burst functions into the code. > Given that there was no "versioning" of the API/ABI in those releases :). > Hehe :)
Yes, API versioning would be a great benefit to this sort of problem. If only there were a patchset available to create that ability ;) Neil
