[Click] Question about cooperating elementclasses

[Philip Prindeville]

I figure 10/8, 172.16/12, and 192.168/16 still have some mileage left in them.


On 2/15/11 2:29 PM, Roman Chertov wrote:
> "The last IPv4 address blocks allocated" http://lwn.net/Articles/425919/
> Time to move to IPv6 and stop using ARP :)
>
>
> On Tue, 15 Feb 2011 13:33:47 -0800 Philip Prindeville
> <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
>>