[Click] Question about cooperating elementclasses

Eddie Kohler kohler at cs.ucla.edu
Thu Feb 17 14:32:11 EST 2011


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
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click


More information about the click mailing list