Re: cvs commit: src/sys/net route.c src/sys/netinet ip_output.c ip_var.h udp_usrreq.c

["Sepherosa Ziehau" <sepherosa@xxxxxxxxx>]

On Sun, Sep 14, 2008 at 5:29 AM, Matthew Dillon
<dillon@apollo.backplane.com> wrote:
>   Sephe, what do you think about putting a port pointer in the
>   socket structure directly and then only calling pr_mport() on socket
>   creation or when the protocol stack decides it needs to be changed?
>
>   I think it might make some of these issues easier to deal with.  Amoung
>   other things we could trivially forward messages sent to the wrong port.

I see, you mean push the mport into proto threads.  However, I don't
think we afford to do that with udp currently, especially with
unconnected udp; the probability that a packet is sent to the wrong
port is proportional to #cpu :)

Or we may add a flag to tell ip_output whether it should check port
and forward accordingly?  This flag could be used on packet forward
path (the port is always correct).

>
>   We could also similarly tag the route table entry, perhaps with a cpuid
>   or globaldata pointer, to detect issues there.

I had added cpuid in the route entry.  On output path, if it is
detected that the passed route entry's cpuid is not the same as
mycpuid, packet is not forwarded as you have mentioned, actually the
port is correct, e.g. in the callgraph like:
ip_input->tcp_input->tcp_respond->ip_output on a tcp server socket.
The port is always correct but the route entry passed to ip_output may
be allocated on different cpu, since we only duplicated tcp server
socket's inp pointer (i.e. inp's route cache is actually shared).

Best Regards,
sephe

-- 
Live Free or Die