Date: Tue, 13 Oct 2020 09:58:54 -0400 From: Dheeraj Kandula <dkandula@gmail.com> To: Hans Petter Selasky <hps@selasky.org> Cc: freebsd-net@freebsd.org Subject: Re: ims_merge in in_mcast.c Message-ID: <CA%2BqNgxQ500U7QpWKMVMwzhzgg=T0gXtuwe7zyoRNu6TUc_cA5g@mail.gmail.com> In-Reply-To: <5f8b19d0-f833-0566-2336-d75ce0881ffa@selasky.org> References: <CA%2BqNgxTMpE9_iT=ZoC78qMEeJPvZMKuG024k8rU2uaL3eKb1sQ@mail.gmail.com> <5f8b19d0-f833-0566-2336-d75ce0881ffa@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks, HPS for the response. I think the index 0 is for a state (previous to current) and 1 indicates the current state. I am still trying to figure out what they really mean. Maybe reading the RFC will shed some light on the intention. My understanding is that the state transition is from index 0 to index 1. Hence when we are reverting, the state has to be reverted from index 1 to index 0. Isn't it? For a regular non-rollback scenario, the operation of -1 on line (987 or 991) and +1 (997 or 1001) adds up to 0. What are we trying to achieve here? Maybe that will help me to understand this code better. Dheeraj On Tue, Oct 13, 2020 at 4:18 AM Hans Petter Selasky <hps@selasky.org> wrote: > On 2020-10-12 19:11, Dheeraj Kandula wrote: > > On line 987 and 991 shouldn't the index be 0 instead of 1. > > > > i.e. ims->ims_st[0].ex -= n; > > and > > ims->ims_st[0].in -= n; > > > > On a rollback, the entry at index 0 is incremented and the entry at > index 1 > > is decremented. > > > > On a non-rollback merge, the entry at index 0 is decremented and the > entry > > at index 1 is incremented. > > Hi, > > If you look at inm_commit() you see that [0] is overwritten by [1], so I > believe the current code is correct. Same goes for both IPv4 and IPv6. > Are you seeing an issue with multicast investigating this issue? > > --HPS >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BqNgxQ500U7QpWKMVMwzhzgg=T0gXtuwe7zyoRNu6TUc_cA5g>