Can you CMR over anything that still needs to go to v1.3 for the sm
I'll be filing a CMR to activate coll_sync later today.
(I admit I didn't pay close attention to see if everything is already
On Jul 2, 2009, at 8:06 AM, Jeff Squyres wrote:
> On Jul 1, 2009, at 10:23 PM, Eugene Loh wrote:
>> > For the future, we have a two pronged plan:
>> I suspect the standard procedure is that we all look quickly at this
>> e-mail message, file appropriately, and then resume our normal lives.
>> Yes? Or, is such a plan put somehow into place?
> I have time to allocate to this starting next week, but I then take
> a week of vacation the week after.
>> > 1. Clean up the sm btl:
>> > 1a. Remove all dead code.
>> What do you mean here? (Possibly you mean getting rid of sm pending
>> sends if we implement 1b properly, but I'm not sure.)
> You mentioned to Brian and me that there was a lot of "dead
> code" (#if'ed out or otherwise will-never-be-used). If that's
> incorrect, then forget this item.
>> > 1b. Resize free_list_max and fifo_size MCA params to effect good
>> > enough flow control.
>> > 1c. Possibly: convert from FIFO's to linked lists (for future
>> > maintenance purposes, not necessarily to fix problems).
>> Another idea is to have two kinds of FIFOs. One is just for
>> fragments. The other is for in-coming message fragments. It would
>> seem as though one would no longer need "free lists", but just use
>> ack FIFO to manage fragments. (ALL of this is complicated by the
>> that we have two kinds of fragments, eager and max, but fortunately
>> those details can be pushed onto the sorry fool who'll be
>> all this. I wonder who that'll be.)
> Likely me and/or Brian.
> Jeff Squyres
> Cisco Systems