[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-net
Subject:    Re: RFC: NFS trunking (multiple TCP connections for a mount
From:       Rick Macklem <rmacklem () uoguelph ! ca>
Date:       2021-06-29 20:22:31
Message-ID: YQXPR0101MB09686A55B3373E452E09B8B7DD029 () YQXPR0101MB0968 ! CANPRD01 ! PROD ! OUTLOOK ! COM
[Download RAW message or body]

Thanks everyone, for your comments. I now see (never used it
nor looked at it before) that lagg/lacp pins traffic for a TCP connection
to an interface (not infallibly for Peter).

I also now learned a little bit w.r.t. multiple queues for fast NICs.

Sounds like the "nconnect" option is worth implementing.

Thanks for your input, rick

________________________________________
From: Peter Eriksson <pen@lysator.liu.se>
Sent: Tuesday, June 29, 2021 5:11 AM
To: Rick Macklem
Cc: freebsd-net
Subject: Re: RFC: NFS trunking (multiple TCP connections for a mount

CAUTION: This email originated from outside of the University of Guelph. Do=
 not click links or open attachments unless you recognize the sender and kn=
ow the content is safe. If in doubt, forward suspicious emails to IThelp@uo=
guelph.ca


> I don't understand how multiple TCP connections to the same
> server IP address will distribute the load across multiple network
> interfaces?
> I thought that lagg would have handled this?


A lagg typically keeps all data in a TCP stream on a specific lagg member (=
depending on how the lagg is set up, unless you select the =93roundrobin=94=
 option in freebsd -  don=92t do that unless you like out-of-order packets=
=85)

Network equipment with laggs typically hash the IP streams over the lagg me=
mbers based on MAC addresses (source&target), IP addresses (source&target) =
and port numbers.

(We have been diagnosing a fun problem locally where we see packet losses/p=
erformance drops over our internal backbone network for certain combination=
s of odd/even IP addresses/port numbers when things pass certain SPB =93rou=
ters=94 (which typically hash the streams over many =93channels=94 between =
routers)=85 Fun fun. :-)

I think the multiple NFS TCP streams could make for some nice performance i=
mprovements in certain cases. And it would be a more generalisation of havi=
ng multiple streams between two hosts - one-or-many over IPv4 and one-or-ma=
ny over IPv6 at the same time. Windows SMB has a similar feature.

Just avoid the Linux NFS mounting deadlock issue with =93down=94 servers pl=
ease  :-)

- Peter

[prev in list] [next in list] [prev in thread] [next in thread]