[EMAIL PROTECTED] writes: > One of the considerations in trying to make ip_xmit_v4() function > with only an nce and not an ire is removing the updating of the > field ire_last_used_time - this is used in calculating the defense > time used in IPv4 DAD.
I already discussed this with Erik ... are you working with him? The ire_last_used_time is used as a heuristic as part of the logic in switching between ips_ip_max_temp_defend and ips_ip_max_defend. It's inessential and the usage could be discarded, but you _do_ need the ipif flags. Here's what I told Erik when he asked about this on July 10th: In this case, all we're concerned about are locally configured IP interface addresses. _Any_ place where local addresses are tagged with recency of use information (such as in an NCE or some sort of ARP cache; not sure about the current refactoring details) would do fine. It doesn't have to be an IRE. You could also just ditch the time-based logic and use the ipif_flags alone to determine the maxdefense value. The underlying idea here was to be slightly less aggressive in defending an address if we've never really used it, on the presumption that losing an unused address is less likely to hurt any running applications, and thus in a fair fight between equal Solaris implementations, you'd want the "active" address user to prevail. But, arguably, it's not that interesting a feature. > Could the above code be changed to work even if there is no knowledge of > the last time a packet was sent or received using an IRE_LOCAL? Sure. If we've got the "address can be easily replaced" flag available -- currently represented by either IPIF_DHCPRUNNING or IPIF_TEMPORARY -- then we can do as above. If we don't have that, then I'd suggest ripping out ips_ip_max_temp_defend and using ips_ip_max_defend alone. That is quite likely to be sufficient in practice. These tunables and the related system behavior are intentionally not documented interfaces, just so we can make changes like this if we need to. > So the question I'd have is what would you see as being the > reason for not putting this into the nce_t? The ire_last_used_time variable isn't my invention. It's been in the code for quite some time. I think it was introduced by: 4416636 Solaris forwarding path does not scale 4456645 Getting TCP/IP status using ndd can "hang" the system It was just a convenient value. > There is IPv6 > behaviour that would also need to be changed. What other > fields are related to DAD here? Do you have any thoughts > on whether some/all of them should be pushed into the nce_t? The other related fields are ire_defense_count and ire_defense_time in the ire_t, and the ipif_flags values in ipif_t. > Is there a technical document I should have a look at that > covers which structures are used and how, or is it just a > matter of reviewing the source code? Section 6.3 of the design document covers the design decisions related to these variables. It doesn't document all of the individual data structure elements, though. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
