[Click] Question about cooperating elementclasses

[Philip Prindeville]

Why not just keep a linked list of all the ARPQuerier instances that an ARPTable is associated with it, and have it iterate over the list?

In the nominal case, that's going to be a single instance of ARPQuerier anyway, so there's no overhead there...

And in my case, I was having to pump a packet either through Tee(n) or else RandomSwitch(n) to and deliver it to all or one load-balanced instances... which I'm guessing is of at least comparable overhead.


On 2/16/11 12:46 PM, Cliff Frey wrote:
> I would say that this is a bug by some definition, but it is a very tricky one to solve.  Specifically, even if you did change the queueing to be in arpquerier, you would still need a pointer back from arptable -> arpquerier so that if an arp response came in on one querier that updated the arptable, the arptable would have to wake up the other arpquerier which had a queued packet.
>
> I think that most people can get around it by just using different arptables for each arpquerier.
>
> Cliff
>
> On Tue, Feb 15, 2011 at 1:33 PM, Philip Prindeville <philipp_subx at redfish-solutions.com <mailto:philipp_subx at redfish-solutions.com>> wrote:
>
>     Thought about this some more, and it's going to be more of a challenge than I thought.
>
>     Part of the problem is that the packets get queued up in the ARPTable, and not in the ARPQuerier, so if you have multiple ARPQuerier instances using the same ARPTable (we do... we're in a threaded/polled environment) then the packet loses the association to the ARPQuerier (and the ARPQuerier's output ports) when it gets queued.
>
>     For that matter, I'm not sure that ARPQuerier::handle_response() is correct: all of the packets get put onto the same queue in the ARPTable, so that when the queue gets drained they might not go out on the output ports of the same instance of ARPQuerier that the came in on.
>
>     Example:
>
>     o1 :: ...
>     o2 :: ...
>     at :: ARPTable();
>
>     ... -> a1 :: ARPQuerier(TABLE at) -> o1;
>     ... -> a2 :: ARPQuerier(TABLE at) -> o2;
>
>     now let's say that packet p1 comes in on a1, and packet p2 comes in on a2.  Both are destined to x.x.x.x.
>
>     Then an ARP response comes back resolving x.x.x.x.
>
>     Both packets will be sent to o1, or o2, depending on whether the answer is delivered to a1 or a2...
>
>     So packets might be "switched" from the a1...o1 path to o2, or vice versa.
>
>     Is this a bug?
>
>     Should the queuing (and queue expiration) be happening in the ARPQuerier class instead?
>
>     -Philip
>
>
>     On 2/12/11 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 <mailto:click at amsterdam.lcs.mit.edu>
>     https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>
>