[Click] Question about cooperating elementclasses

[Philip Prindeville]

Don't agree.  I don't care if they get run on the same thread, but I definitely want the flow through the system maintained...

Can't really go into all the reasons on the list without compromising my employer's intellectual property, however.


On 2/17/11 2:36 PM, Eddie Kohler wrote:
> 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
>>