Re: [PATCH v2 1/2] nvmet-tcp: support specifying the congestion-control

[Mingbao Sun]

On Thu, 10 Mar 2022 19:06:36 +0800
Mingbao Sun <sunmingbao@xxxxxxx> wrote:

> On Thu, 10 Mar 2022 09:38:11 +0100
> Christoph Hellwig <hch@xxxxxx> wrote:
> 
> > On Wed, Mar 09, 2022 at 05:52:03PM +0800, Mingbao Sun wrote:
> > > On Wed, 9 Mar 2022 07:15:41 +0100
> > > Christoph Hellwig <hch@xxxxxx> wrote:
> > >   
> > > > On Wed, Mar 09, 2022 at 01:37:11PM +0800, Mingbao Sun wrote:  
> > > > > +		if (port->nport->tcp_congestion) {
> > > > > +			icsk_new = inet_csk(newsock->sk);
> > > > > +			if (icsk_new->icsk_ca_ops != icsk->icsk_ca_ops) {
> > > > > +				pr_warn("congestion abnormal: expected %s, actual %s.\n",
> > > > > +					icsk->icsk_ca_ops->name,
> > > > > +					icsk_new->icsk_ca_ops->name);
> > > > > +			}
> > > > > +		}    
> > > > 
> > > > What is the point of having this code?  
> > > 
> > > Well, this could happen in certain circumstances.
> > > Take the result from my test as an example:
> > > 
> > >     - The congestion of the listening socket of the target was set to
> > >       ‘dctcp’.
> > > 
> > >     - But the congestion of the socket of the host side was set to
> > >       ‘cubic’.
> > > 
> > >     - Then the congestion of the socket of the new connection at the
> > >       target side would automatically be altered to ‘dctcp-reno’.
> > > 
> > > In case tcp_congestion was explicitly set for the target, it can be
> > > supposed that the user attaches great importance to performance.
> > > So we’d better make the users aware that the system is not working
> > > in the way they expect.   
> > 
> > A warning message really seems very severe for a condition like this.
> > Maybe the better interface is a way to figure out which congestion
> > control algorithm is in use by reading a sysfs file.
> 
> Well, a target could have a great number of TCP sockets.
> 
> I feel it’s not proper to create a sysfs entry for each socket.
> And for those sockets that do not have the exception of
> congestion-control, it’s merely a waste of resources.
> 
> Also, since these sockets generate and die dynamically, the info
> exported via fs may even do not have the opportunity to be seen by
> the user.
> 
> Anyway, if you insist that the checking and warning here is not proper,
> I can remove it. 

How about replacing pr_warn with pr_warn_once?