On Tue, Apr 15, 2014 at 9:19 PM, Joe Stringer <j...@wand.net.nz> wrote:
> (Apologies for the delay on this discussion)
>
> On 11 April 2014 16:54, Alex Wang <al...@nicira.com> wrote:
>
>> On Thu, Apr 10, 2014 at 7:49 PM, Joe Stringer <j...@wand.net.nz> wrote:
>>
>>> On 11 April 2014 10:59, Alex Wang <al...@nicira.com> wrote:
>>>
>>>> diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
>>>> index 04d5454..7f327b9 100644
>>>> --- a/ofproto/ofproto-dpif.c
>>>> +++ b/ofproto/ofproto-dpif.c
>>>> @@ -375,6 +375,8 @@ ofproto_dpif_send_packet_in(struct ofproto_dpif
>>>> *ofproto,
>>>> COVERAGE_INC(packet_in_overflow);
>>>> free(CONST_CAST(void *, pin->up.packet));
>>>> free(pin);
>>>> + } else {
>>>> + seq_change(connectivity_seq_get());
>>>> }
>>>> }
>>>>
>>>>
>>> Why do we modify the connectivity status each time there is a packet_in?
>>>
>>
>>
>> This relates to your first summary point. ;D
>> Originally, ofproto_dpif_send_packet_in() depends on ovs-vswitchd() be
>> waken up every 100ms to
>> schedule the transmission in connmgr module. Now, since the 'Instant'
>> stats logic is removed,
>> we need to explicitly notify the global seq. Otherwise, the main thread
>> will keep sleeping.
>>
>> Found it in a unittest failure.
>>
>
> Is there any reason that this is tied to the connectivity_seq, as opposed
> to a 'struct seq' attached to the connmgr?
>
>>
>
The main reason is that the 'ofproto_dpif_send_packet_in()' only puts it in
the 'ofproto->pins' list. And in the run(), those 'pins'
are given to connmgr via connmgr_send_packet_in(). So, connectivity_seq is
to force a run().
Another issue is that, we are doing rate-limiting for packet-ins in connmgr
module. My initial thought is that it will be complicated
to involve 'struct seq'. I'll dig more into it.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
