Reset is fine, given that internally it just calls t3_send_reset. On 12/16/07, Robert Watson <rwatson_at_freebsd.org> wrote: > > On Sat, 15 Dec 2007, Kip Macy wrote: > > >> + * + tu_abort > >> + * - closes the connection and sends a RST to peer > >> + * - driver is expectd to trigger an RST and detach the toepcb > >> > >> In regular TCP, the pru_abort method is only called on pending > connections > >> while still in the listen queues of a listen socket. Is this true of > >> tu_abort, or is tu_abort a more general method to be used to cancel > >> connections? If so, probably worth commenting on that. > > > > tu_abort is called in place of tcp_output in pru_abort. > > The reason I ask is that it appears tu_abort appears to be the only > interface > allowing the stack to request that TOE reset of a connection. In regular > TCP, > soabort/pru_abort/tcp_usr_abort are used only on nascent unaccepted > connections; at least one other path, used by tcpdrop(8), can lead to > connections being reset as well. Perhaps a more general tu_reset could be > used to address this? I'm not sure what other direct-to-reset paths exist > but > a review for them may be called for. > > Robert N M Watson > Computer Laboratory > University of Cambridge >Received on Sun Dec 16 2007 - 15:48:13 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:24 UTC