Project

General

Profile

Actions
Copy link

Bug #943

closed

route entry and tcp_usr_connect/tcp_connect

Added by sepherosa about 16 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Hi,

It turns out the previous problem (tcp_timer_2msl) is related to
calling tcp_output() in tcp_usr_connect() and tcp_connect().
For TCP PRU_CONNECT is handled on tcp_thread0 following two
functions are executed in that thread:
tcp_connect() and tcp_output()

tcp_connect() will call in_pcbladdr() if source address is INADDR_ANY,
then inp's route will be filled. If the target port of this TCP
connection is not tcp_thread0's port then we actually use an route
entry on a different CPU and will unref it on different CPU. If we
free the route entry allocated in in_pcbladdr() if target port is not
tcp_thread0's port, then tcp_output() in tcp_usr_connect() will
cause problem too, since it is called in tcp_thread0, an route entry
in CPU0 will still be installed to inp's route.

So I made following patch:
- If target port is not tcp_thread0's port, then we free the route
entry allocated by in_pcbladdr().
- In tcp_usr_connect(), if target port is not tcp_thread0's port, we
dispatch tcp_output to the target port to be called.

Please review it:
http://leaf.dragonflybsd.org/~sephe/tcp_connect.diff

Best Regards,
sephe

Actions
Copy link
 #1

Updated by dillon about 16 years ago

:Hi,
:
:It turns out the previous problem (tcp_timer_2msl) is related to
:calling tcp_output() in tcp_usr_connect() and tcp_connect().
:For TCP PRU_CONNECT is handled on tcp_thread0 following two
:functions are executed in that thread:
:tcp_connect() and tcp_output()
:
:...
:So I made following patch:
:- If target port is not tcp_thread0's port, then we free the route
:entry allocated by in_pcbladdr().
:- In tcp_usr_connect(), if target port is not tcp_thread0's port, we
:dispatch tcp_output to the target port to be called.
:
:Please review it:
:http://leaf.dragonflybsd.org/~sephe/tcp_connect.diff
:
:Best Regards,
:sephe

I like it.  We should probably also start adding cpu-assertions to the
    tcp protocol stack, as a step towards removing the BGL from the protocol
    stack threads.
-Matt
                    Matthew Dillon 
                    <>
Actions
Copy link
 #3

Updated by martin1234 over 5 years ago

  • Description updated (diff)
Actions
Copy link

Also available in: Atom PDF