[Click] Question about cooperating elementclasses

[Eddie Kohler]

But in this case, right, it doesn't actually matter whether we map packets to 
the "correct" ARPQuerier?  We don't expect many packets to get dropped, or 
even queued; it's not super performance sensitive.  It'd definitely be easier 
to emit packets to SOME Querier than it would be to emit them to the ENQUEUING 
ARPQuerier.

Eddie


On 02/17/2011 01:28 PM, Philip Prindeville wrote:
> Yes, busted.
>
> It's a RouterBricks thing.
>
> And yes, you guessed exactly right.
>
>
> On 2/17/11 11:32 AM, Eddie Kohler wrote:
>> Hey Philip,
>>
>> Thanks for your patience...
>>
>> It is certainly possible that ARPQuerier should do the queueing instead of
>> ARPTable.
>>
>> The "logic" for for the current behavior is as follows: ARP responses are
>> sensitive to a given NIC, so if multiple ARPQueriers share an ARPTable, it's
>> OK that all queued packets are emitted from *WHICHEVER* ARPQuerier happens
>> to receive the response.
>>
>> I don't completely buy this "logic". But could you explain more about your
>> application, to help me understand the ideal final behavior? Why do you want
>> to share ARPTables? Is this a sort of a RouterBricks thing, where you have
>> multiple ARPQueriers on different threads, writing to multiple output queues
>> on THE SAME output NIC?
>>
>> Eddie
>>
>>
>> On 02/12/2011 11:22 AM, Philip Prindeville wrote:
>>> I wanted to make a change to ARPTable which would give it the ability to
>>> invoke a hook back to ARPQuerier when it deletes queued up packages, but
>>> wasn't sure if there's a clean way to do this.
>>>
>>> In C, I'd just set a pointer to a callback function, but this isn't C.
>>>
>>> So what's the best way to do it? Keep in mind that the ARPTable might have
>>> been
>>>
>>> Also, it's the case that the same ARPTable instance might be shared amongst
>>> several ARPQuerier instances (because we're in a multi-core environment
>>> with several threads running on the same NIC).
>>>
>>> Oh, one other question about ARPTable vs. ARPQuerier interactions... if I
>>> have that same situation where I'm running multithreaded, and a response
>>> packet gets delivered to one ARPQuerier, thereby updating the ARPTable...
>>> will the queued up packets in each instance of the ARPQueriers get updated
>>> and unblock the packets?
>>>
>>> Or are the queued packets actually held by the ARPTable (and therefore in a
>>> single place)?
>>>
>>> Looking at how ARPQuerier::handle_ip() and ARPQuerier::handle_response()
>>> interact, it looks like the packets are all held by the ARPTable, and when
>>> the queue gets drained, all drained by the same instance... so any affinity
>>> of individual packets to threads is lost.
>>>
>>> Packet *cached_packet;
>>> arpt->insert(ipa, ena,&cached_packet);
>>>
>>> while (cached_packet) {
>>> Packet *next = cached_packet->next();
>>> handle_ip(cached_packet, true);
>>> cached_packet = next;
>>> }
>>>
>>>
>>> Correct?
>>>
>>> Thanks.
>>>
>>> -Philip
>