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_s...@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@amsterdam.lcs.mit.edu https://amsterdam.lcs.mit.edu/mailman/listinfo/click
