Sebastien Roy wrote:
On Fri, 2009-09-04 at 15:04 -0700, Erik Nordmark wrote:
The design review for IP Datapath refactoring starts next week and will
run for 2 weeks. The project page is at
http://opensolaris.org/os/project/ip-refactor/
There is a design document detailing the changes at
http://opensolaris.org/os/project/ip-refactor/ip-refactor-changes.pdf
Excellent document, I have a couple of minor questions:
Thanks for the comments.
Section 5.1.2: This also does a bind to a local address? Does this use
ip_verify_laddr*() under the hood?
There is no need to.
If the application called bind() the ULP called ip_verify_laddr* at that
point in time.
If the application didn't call bind specifying a local IP address, then
when it calls connect() or sendto() causing the call to conn_connect()
or ip_attr_connect(), those routines just assign a local address. Hence
no need to verify that the address is valid.
Regarding the receive side ULP interfaces (section 5.3), you mention
that ICMP errors are now delivered through conn_recvicmp() which
replaces the M_CTL mechanism. Does that mean that ULPs have a different
functional entry-point for ICMP errors that hook into conn_recvicmp()?
Yes.
(They typically already had such a routine which they called themselves
to handle the ICMP M_CTLs.)
Section 6.4: Will the new notify interfaces allow us to implement a
feature whereby we set a non-existent "local" address on the tunnel, and
then bind to it when we get notified that this address is created?
Currently, one needs to wait until other IP addresses are created on the
system prior to creating IP tunnel links, which is awkward.
You could allow the tunnels to be created, and if packets were sent to
conn_ip_output() they would be dropped and EADDRNOTAVAIL be returned.
Then when that local IP address is configured, conn_ip_output would no
longer drop those packets.
But there isn't any asynchronous notification indicating that a new IP
address has arrived.
Section 10.3.1: And the iptun default queue.
I'll add that.
Section 10.8.1: Does this change also imply that the IPv4 and IPv6
source address selection functions now both use the same "rules-based"
algorithm as is currently done in ipif_select_source_v6()?
No. We still have the ipif_select_source{,_v6} which haven't really
changed. The IPv6 variant uses the rules as before.
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
