* [PATCH v2 net-next] net: introduce SO_RCVBUFAUTO to let the rcv_buf tune automatically
@ 2022-02-16 5:03 kerneljasonxing
2022-02-16 6:24 ` Eric Dumazet
2022-02-16 8:47 ` kernel test robot
0 siblings, 2 replies; 6+ messages in thread
From: kerneljasonxing @ 2022-02-16 5:03 UTC (permalink / raw)
To: davem, kuba, ast, daniel, andrii, kafai, songliubraving, yhs,
john.fastabend, kpsingh, edumazet, pabeni, weiwan, aahringo,
yangbo.lu, fw, xiangxia.m.yue, tglx
Cc: netdev, linux-kernel, bpf, kerneljasonxing, Jason Xing
From: Jason Xing <xingwanli@kuaishou.com>
Normally, user doesn't care the logic behind the kernel if they're
trying to set receive buffer via setsockopt. However, once the new
value of the receive buffer is set even though it's not smaller than
the initial value which is sysctl_tcp_rmem[1] implemented in
tcp_rcv_space_adjust(),, the server's wscale will shrink and then
lead to the bad bandwidth as intended.
For now, introducing a new socket option to let the receive buffer
grow automatically no matter what the new value is can solve
the bad bandwidth issue meanwhile it's not breaking the application
with SO_RCVBUF option set.
Here are some numbers:
$ sysctl -a | grep rmem
net.core.rmem_default = 212992
net.core.rmem_max = 40880000
net.ipv4.tcp_rmem = 4096 425984 40880000
Case 1
on the server side
# iperf -s -p 5201
on the client side
# iperf -c [client ip] -p 5201
It turns out that the bandwidth is 9.34 Gbits/sec while the wscale of
server side is 10. It's good.
Case 2
on the server side
#iperf -s -p 5201 -w 425984
on the client side
# iperf -c [client ip] -p 5201
It turns out that the bandwidth is reduced to 2.73 Gbits/sec while the
wcale is 2, even though the receive buffer is not changed at all at the
very beginning.
After this patch is applied, the bandwidth of case 2 is recovered to
9.34 Gbits/sec as expected at the cost of consuming more memory per
socket.
Signed-off-by: Jason Xing <xingwanli@kuaishou.com>
--
v2: suggested by Eric
- introduce new socket option instead of breaking the logic in SO_RCVBUF
- Adjust the title and description of this patch
link: https://lore.kernel.org/lkml/CANn89iL8vOUOH9bZaiA-cKcms+PotuKCxv7LpVx3RF0dDDSnmg@mail.gmail.com/
---
include/uapi/asm-generic/socket.h | 1 +
net/core/sock.c | 18 +++++++++++++-----
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/include/uapi/asm-generic/socket.h b/include/uapi/asm-generic/socket.h
index c77a131..f4ce79b 100644
--- a/include/uapi/asm-generic/socket.h
+++ b/include/uapi/asm-generic/socket.h
@@ -18,6 +18,7 @@
#define SO_RCVBUF 8
#define SO_SNDBUFFORCE 32
#define SO_RCVBUFFORCE 33
+#define SO_RCVBUFAUTO 74
#define SO_KEEPALIVE 9
#define SO_OOBINLINE 10
#define SO_NO_CHECK 11
diff --git a/net/core/sock.c b/net/core/sock.c
index 4ff806d..8565684 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -917,13 +917,14 @@ void sock_set_keepalive(struct sock *sk)
}
EXPORT_SYMBOL(sock_set_keepalive);
-static void __sock_set_rcvbuf(struct sock *sk, int val)
+static void __sock_set_rcvbuf(struct sock *sk, int val, bool is_set)
{
/* Ensure val * 2 fits into an int, to prevent max_t() from treating it
* as a negative value.
*/
val = min_t(int, val, INT_MAX / 2);
- sk->sk_userlocks |= SOCK_RCVBUF_LOCK;
+ if (is_set)
+ sk->sk_userlocks |= SOCK_RCVBUF_LOCK;
/* We double it on the way in to account for "struct sk_buff" etc.
* overhead. Applications assume that the SO_RCVBUF setting they make
@@ -941,7 +942,7 @@ static void __sock_set_rcvbuf(struct sock *sk, int val)
void sock_set_rcvbuf(struct sock *sk, int val)
{
lock_sock(sk);
- __sock_set_rcvbuf(sk, val);
+ __sock_set_rcvbuf(sk, val, true);
release_sock(sk);
}
EXPORT_SYMBOL(sock_set_rcvbuf);
@@ -1106,7 +1107,7 @@ int sock_setsockopt(struct socket *sock, int level, int optname,
* play 'guess the biggest size' games. RCVBUF/SNDBUF
* are treated in BSD as hints
*/
- __sock_set_rcvbuf(sk, min_t(u32, val, sysctl_rmem_max));
+ __sock_set_rcvbuf(sk, min_t(u32, val, sysctl_rmem_max), true);
break;
case SO_RCVBUFFORCE:
@@ -1118,7 +1119,14 @@ int sock_setsockopt(struct socket *sock, int level, int optname,
/* No negative values (to prevent underflow, as val will be
* multiplied by 2).
*/
- __sock_set_rcvbuf(sk, max(val, 0));
+ __sock_set_rcvbuf(sk, max(val, 0), true);
+ break;
+
+ case SO_RCVBUFAUTO:
+ /* Though similar to SO_RCVBUF, we do not use userlocks in
+ * order to let the receive buffer tune automatically.
+ */
+ __sock_set_rcvbuf(sk, min_t(u32, val, sysctl_rmem_max), false);
break;
case SO_KEEPALIVE:
--
1.8.3.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v2 net-next] net: introduce SO_RCVBUFAUTO to let the rcv_buf tune automatically
2022-02-16 5:03 [PATCH v2 net-next] net: introduce SO_RCVBUFAUTO to let the rcv_buf tune automatically kerneljasonxing
@ 2022-02-16 6:24 ` Eric Dumazet
2022-02-16 6:57 ` Jason Xing
2022-02-16 8:47 ` kernel test robot
1 sibling, 1 reply; 6+ messages in thread
From: Eric Dumazet @ 2022-02-16 6:24 UTC (permalink / raw)
To: Jason Xing
Cc: David Miller, Jakub Kicinski, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Paolo Abeni, Wei Wang,
Alexander Aring, Yangbo Lu, Florian Westphal, Tonghao Zhang,
Thomas Gleixner, netdev, LKML, bpf, Jason Xing
On Tue, Feb 15, 2022 at 9:03 PM <kerneljasonxing@gmail.com> wrote:
>
> From: Jason Xing <xingwanli@kuaishou.com>
>
> Normally, user doesn't care the logic behind the kernel if they're
> trying to set receive buffer via setsockopt. However, once the new
> value of the receive buffer is set even though it's not smaller than
> the initial value which is sysctl_tcp_rmem[1] implemented in
> tcp_rcv_space_adjust(),, the server's wscale will shrink and then
> lead to the bad bandwidth as intended.
Quite confusing changelog, honestly.
Users of SO_RCVBUF specifically told the kernel : I want to use _this_
buffer size, I do not want the kernel to decide for me.
Also, I think your changelog does not really explain that _if_ you set
SO_RCVBUF to a small value before
connect() or in general the 3WHS, the chosen wscale will be small, and
this won't allow future 10x increase
of the effective RWIN.
>
> For now, introducing a new socket option to let the receive buffer
> grow automatically no matter what the new value is can solve
> the bad bandwidth issue meanwhile it's not breaking the application
> with SO_RCVBUF option set.
>
> Here are some numbers:
> $ sysctl -a | grep rmem
> net.core.rmem_default = 212992
> net.core.rmem_max = 40880000
> net.ipv4.tcp_rmem = 4096 425984 40880000
>
> Case 1
> on the server side
> # iperf -s -p 5201
> on the client side
> # iperf -c [client ip] -p 5201
> It turns out that the bandwidth is 9.34 Gbits/sec while the wscale of
> server side is 10. It's good.
>
> Case 2
> on the server side
> #iperf -s -p 5201 -w 425984
> on the client side
> # iperf -c [client ip] -p 5201
> It turns out that the bandwidth is reduced to 2.73 Gbits/sec while the
> wcale is 2, even though the receive buffer is not changed at all at the
> very beginning.
>
> After this patch is applied, the bandwidth of case 2 is recovered to
> 9.34 Gbits/sec as expected at the cost of consuming more memory per
> socket.
How does your patch allow wscale to increase after flow is established ?
I would remove from the changelog these experimental numbers that look
quite wrong,
maybe copy/pasted from your prior version.
Instead I would describe why an application might want to clear the
'receive buffer size is locked' socket attribute.
>
> Signed-off-by: Jason Xing <xingwanli@kuaishou.com>
> --
> v2: suggested by Eric
> - introduce new socket option instead of breaking the logic in SO_RCVBUF
> - Adjust the title and description of this patch
> link: https://lore.kernel.org/lkml/CANn89iL8vOUOH9bZaiA-cKcms+PotuKCxv7LpVx3RF0dDDSnmg@mail.gmail.com/
> ---
>
I think adding another parallel SO_RCVBUF option is not good. It is
adding confusion (and net/core/filter.c has been unchanged)
Also we want CRIU to work correctly.
So if you have a SO_XXXX setsockopt() call, you also need to provide
getsockopt() implementation.
I would suggest an option to clear or set SOCK_RCVBUF_LOCK, and
getsockopt() would return if the bit is currently set or not.
Something clearly describing the intent, like SO_RCVBUF_LOCK maybe.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 net-next] net: introduce SO_RCVBUFAUTO to let the rcv_buf tune automatically
2022-02-16 6:24 ` Eric Dumazet
@ 2022-02-16 6:57 ` Jason Xing
2022-02-16 16:56 ` Eric Dumazet
0 siblings, 1 reply; 6+ messages in thread
From: Jason Xing @ 2022-02-16 6:57 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Jakub Kicinski, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Paolo Abeni, Wei Wang,
Alexander Aring, Yangbo Lu, Florian Westphal, Tonghao Zhang,
Thomas Gleixner, netdev, LKML, bpf, Jason Xing
On Wed, Feb 16, 2022 at 2:25 PM Eric Dumazet <edumazet@google.com> wrote:
>
> On Tue, Feb 15, 2022 at 9:03 PM <kerneljasonxing@gmail.com> wrote:
> >
> > From: Jason Xing <xingwanli@kuaishou.com>
> >
> > Normally, user doesn't care the logic behind the kernel if they're
> > trying to set receive buffer via setsockopt. However, once the new
> > value of the receive buffer is set even though it's not smaller than
> > the initial value which is sysctl_tcp_rmem[1] implemented in
> > tcp_rcv_space_adjust(),, the server's wscale will shrink and then
> > lead to the bad bandwidth as intended.
>
> Quite confusing changelog, honestly.
>
> Users of SO_RCVBUF specifically told the kernel : I want to use _this_
> buffer size, I do not want the kernel to decide for me.
>
> Also, I think your changelog does not really explain that _if_ you set
> SO_RCVBUF to a small value before
> connect() or in general the 3WHS, the chosen wscale will be small, and
> this won't allow future 10x increase
> of the effective RWIN.
>
Yes, you hit the point really.
>
> >
> > For now, introducing a new socket option to let the receive buffer
> > grow automatically no matter what the new value is can solve
> > the bad bandwidth issue meanwhile it's not breaking the application
> > with SO_RCVBUF option set.
> >
> > Here are some numbers:
> > $ sysctl -a | grep rmem
> > net.core.rmem_default = 212992
> > net.core.rmem_max = 40880000
> > net.ipv4.tcp_rmem = 4096 425984 40880000
> >
> > Case 1
> > on the server side
> > # iperf -s -p 5201
> > on the client side
> > # iperf -c [client ip] -p 5201
> > It turns out that the bandwidth is 9.34 Gbits/sec while the wscale of
> > server side is 10. It's good.
> >
> > Case 2
> > on the server side
> > #iperf -s -p 5201 -w 425984
> > on the client side
> > # iperf -c [client ip] -p 5201
> > It turns out that the bandwidth is reduced to 2.73 Gbits/sec while the
> > wcale is 2, even though the receive buffer is not changed at all at the
> > very beginning.
> >
> > After this patch is applied, the bandwidth of case 2 is recovered to
> > 9.34 Gbits/sec as expected at the cost of consuming more memory per
> > socket.
>
> How does your patch allow wscale to increase after flow is established ?
>
> I would remove from the changelog these experimental numbers that look
> quite wrong,
> maybe copy/pasted from your prior version.
>
My fault. I should have removed this part.
> Instead I would describe why an application might want to clear the
> 'receive buffer size is locked' socket attribute.
>
> >
> > Signed-off-by: Jason Xing <xingwanli@kuaishou.com>
> > --
> > v2: suggested by Eric
> > - introduce new socket option instead of breaking the logic in SO_RCVBUF
> > - Adjust the title and description of this patch
> > link: https://lore.kernel.org/lkml/CANn89iL8vOUOH9bZaiA-cKcms+PotuKCxv7LpVx3RF0dDDSnmg@mail.gmail.com/
> > ---
> >
>
> I think adding another parallel SO_RCVBUF option is not good. It is
> adding confusion (and net/core/filter.c has been unchanged)
I'll change the filter.c altogether in the next submission.
>
> Also we want CRIU to work correctly.
>
> So if you have a SO_XXXX setsockopt() call, you also need to provide
> getsockopt() implementation.
>
> I would suggest an option to clear or set SOCK_RCVBUF_LOCK, and
> getsockopt() would return if the bit is currently set or not.
>
> Something clearly describing the intent, like SO_RCVBUF_LOCK maybe.
Just now, I found out that the latest kernel has merged a similar
patch (commit 04190bf89) about three months ago.
Is it still necessary to add another separate option to clear the
SOCK_RCVBUF_LOCK explicitly?
Thanks,
Jason
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 net-next] net: introduce SO_RCVBUFAUTO to let the rcv_buf tune automatically
2022-02-16 5:03 [PATCH v2 net-next] net: introduce SO_RCVBUFAUTO to let the rcv_buf tune automatically kerneljasonxing
2022-02-16 6:24 ` Eric Dumazet
@ 2022-02-16 8:47 ` kernel test robot
1 sibling, 0 replies; 6+ messages in thread
From: kernel test robot @ 2022-02-16 8:47 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 11500 bytes --]
Hi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/kerneljasonxing-gmail-com/net-introduce-SO_RCVBUFAUTO-to-let-the-rcv_buf-tune-automatically/20220216-130549
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git b0471c26108160217fc17acec4a9fdce92aaeeea
config: nios2-defconfig (https://download.01.org/0day-ci/archive/20220216/202202161604.JJGbw1Fl-lkp(a)intel.com/config)
compiler: nios2-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/83d2852811bd798510fe870fd596d4aadfa87692
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review kerneljasonxing-gmail-com/net-introduce-SO_RCVBUFAUTO-to-let-the-rcv_buf-tune-automatically/20220216-130549
git checkout 83d2852811bd798510fe870fd596d4aadfa87692
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=nios2 SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
net/core/sock.c: In function 'sock_setsockopt':
>> net/core/sock.c:1458:9: error: duplicate case value
1458 | case SO_TXREHASH:
| ^~~~
net/core/sock.c:1125:9: note: previously used here
1125 | case SO_RCVBUFAUTO:
| ^~~~
vim +1458 net/core/sock.c
62748f32d501f5d Eric Dumazet 2013-09-24 1355
62748f32d501f5d Eric Dumazet 2013-09-24 1356 case SO_MAX_PACING_RATE:
6bdef102dae9d24 Eric Dumazet 2019-02-28 1357 {
700465fd338fe5d Ke Li 2020-10-22 1358 unsigned long ulval = (val == ~0U) ? ~0UL : (unsigned int)val;
6bdef102dae9d24 Eric Dumazet 2019-02-28 1359
6bdef102dae9d24 Eric Dumazet 2019-02-28 1360 if (sizeof(ulval) != sizeof(val) &&
6bdef102dae9d24 Eric Dumazet 2019-02-28 1361 optlen >= sizeof(ulval) &&
c8c1bbb6eb49810 Christoph Hellwig 2020-07-23 1362 copy_from_sockptr(&ulval, optval, sizeof(ulval))) {
6bdef102dae9d24 Eric Dumazet 2019-02-28 1363 ret = -EFAULT;
6bdef102dae9d24 Eric Dumazet 2019-02-28 1364 break;
6bdef102dae9d24 Eric Dumazet 2019-02-28 1365 }
6bdef102dae9d24 Eric Dumazet 2019-02-28 1366 if (ulval != ~0UL)
218af599fa635b1 Eric Dumazet 2017-05-16 1367 cmpxchg(&sk->sk_pacing_status,
218af599fa635b1 Eric Dumazet 2017-05-16 1368 SK_PACING_NONE,
218af599fa635b1 Eric Dumazet 2017-05-16 1369 SK_PACING_NEEDED);
6bdef102dae9d24 Eric Dumazet 2019-02-28 1370 sk->sk_max_pacing_rate = ulval;
6bdef102dae9d24 Eric Dumazet 2019-02-28 1371 sk->sk_pacing_rate = min(sk->sk_pacing_rate, ulval);
62748f32d501f5d Eric Dumazet 2013-09-24 1372 break;
6bdef102dae9d24 Eric Dumazet 2019-02-28 1373 }
70da268b569d32a Eric Dumazet 2015-10-08 1374 case SO_INCOMING_CPU:
7170a977743b72c Eric Dumazet 2019-10-30 1375 WRITE_ONCE(sk->sk_incoming_cpu, val);
70da268b569d32a Eric Dumazet 2015-10-08 1376 break;
70da268b569d32a Eric Dumazet 2015-10-08 1377
a87cb3e48ee86d2 Tom Herbert 2016-02-24 1378 case SO_CNX_ADVICE:
a87cb3e48ee86d2 Tom Herbert 2016-02-24 1379 if (val == 1)
a87cb3e48ee86d2 Tom Herbert 2016-02-24 1380 dst_negative_advice(sk);
a87cb3e48ee86d2 Tom Herbert 2016-02-24 1381 break;
76851d1212c1136 Willem de Bruijn 2017-08-03 1382
76851d1212c1136 Willem de Bruijn 2017-08-03 1383 case SO_ZEROCOPY:
28190752c709272 Sowmini Varadhan 2018-02-15 1384 if (sk->sk_family == PF_INET || sk->sk_family == PF_INET6) {
42f67eea3ba36ce Eric Dumazet 2021-11-15 1385 if (!(sk_is_tcp(sk) ||
b5947e5d1e710c3 Willem de Bruijn 2018-11-30 1386 (sk->sk_type == SOCK_DGRAM &&
b5947e5d1e710c3 Willem de Bruijn 2018-11-30 1387 sk->sk_protocol == IPPROTO_UDP)))
76851d1212c1136 Willem de Bruijn 2017-08-03 1388 ret = -ENOTSUPP;
28190752c709272 Sowmini Varadhan 2018-02-15 1389 } else if (sk->sk_family != PF_RDS) {
28190752c709272 Sowmini Varadhan 2018-02-15 1390 ret = -ENOTSUPP;
28190752c709272 Sowmini Varadhan 2018-02-15 1391 }
28190752c709272 Sowmini Varadhan 2018-02-15 1392 if (!ret) {
28190752c709272 Sowmini Varadhan 2018-02-15 1393 if (val < 0 || val > 1)
76851d1212c1136 Willem de Bruijn 2017-08-03 1394 ret = -EINVAL;
76851d1212c1136 Willem de Bruijn 2017-08-03 1395 else
76851d1212c1136 Willem de Bruijn 2017-08-03 1396 sock_valbool_flag(sk, SOCK_ZEROCOPY, valbool);
28190752c709272 Sowmini Varadhan 2018-02-15 1397 }
334e6413134bf83 Jesus Sanchez-Palencia 2018-03-07 1398 break;
334e6413134bf83 Jesus Sanchez-Palencia 2018-03-07 1399
80b14dee2bea128 Richard Cochran 2018-07-03 1400 case SO_TXTIME:
790709f24972864 Eric Dumazet 2020-05-07 1401 if (optlen != sizeof(struct sock_txtime)) {
80b14dee2bea128 Richard Cochran 2018-07-03 1402 ret = -EINVAL;
790709f24972864 Eric Dumazet 2020-05-07 1403 break;
c8c1bbb6eb49810 Christoph Hellwig 2020-07-23 1404 } else if (copy_from_sockptr(&sk_txtime, optval,
80b14dee2bea128 Richard Cochran 2018-07-03 1405 sizeof(struct sock_txtime))) {
80b14dee2bea128 Richard Cochran 2018-07-03 1406 ret = -EFAULT;
790709f24972864 Eric Dumazet 2020-05-07 1407 break;
80b14dee2bea128 Richard Cochran 2018-07-03 1408 } else if (sk_txtime.flags & ~SOF_TXTIME_FLAGS_MASK) {
80b14dee2bea128 Richard Cochran 2018-07-03 1409 ret = -EINVAL;
790709f24972864 Eric Dumazet 2020-05-07 1410 break;
790709f24972864 Eric Dumazet 2020-05-07 1411 }
790709f24972864 Eric Dumazet 2020-05-07 1412 /* CLOCK_MONOTONIC is only used by sch_fq, and this packet
790709f24972864 Eric Dumazet 2020-05-07 1413 * scheduler has enough safe guards.
790709f24972864 Eric Dumazet 2020-05-07 1414 */
790709f24972864 Eric Dumazet 2020-05-07 1415 if (sk_txtime.clockid != CLOCK_MONOTONIC &&
790709f24972864 Eric Dumazet 2020-05-07 1416 !ns_capable(sock_net(sk)->user_ns, CAP_NET_ADMIN)) {
790709f24972864 Eric Dumazet 2020-05-07 1417 ret = -EPERM;
790709f24972864 Eric Dumazet 2020-05-07 1418 break;
790709f24972864 Eric Dumazet 2020-05-07 1419 }
80b14dee2bea128 Richard Cochran 2018-07-03 1420 sock_valbool_flag(sk, SOCK_TXTIME, true);
80b14dee2bea128 Richard Cochran 2018-07-03 1421 sk->sk_clockid = sk_txtime.clockid;
80b14dee2bea128 Richard Cochran 2018-07-03 1422 sk->sk_txtime_deadline_mode =
80b14dee2bea128 Richard Cochran 2018-07-03 1423 !!(sk_txtime.flags & SOF_TXTIME_DEADLINE_MODE);
4b15c7075352668 Jesus Sanchez-Palencia 2018-07-03 1424 sk->sk_txtime_report_errors =
4b15c7075352668 Jesus Sanchez-Palencia 2018-07-03 1425 !!(sk_txtime.flags & SOF_TXTIME_REPORT_ERRORS);
80b14dee2bea128 Richard Cochran 2018-07-03 1426 break;
80b14dee2bea128 Richard Cochran 2018-07-03 1427
f5dd3d0c9638a9d David Herrmann 2019-01-15 1428 case SO_BINDTOIFINDEX:
7594888c782e735 Christoph Hellwig 2020-05-28 1429 ret = sock_bindtoindex_locked(sk, val);
f5dd3d0c9638a9d David Herrmann 2019-01-15 1430 break;
f5dd3d0c9638a9d David Herrmann 2019-01-15 1431
04190bf8944deb7 Pavel Tikhomirov 2021-08-04 1432 case SO_BUF_LOCK:
04190bf8944deb7 Pavel Tikhomirov 2021-08-04 1433 if (val & ~SOCK_BUF_LOCK_MASK) {
04190bf8944deb7 Pavel Tikhomirov 2021-08-04 1434 ret = -EINVAL;
04190bf8944deb7 Pavel Tikhomirov 2021-08-04 1435 break;
04190bf8944deb7 Pavel Tikhomirov 2021-08-04 1436 }
04190bf8944deb7 Pavel Tikhomirov 2021-08-04 1437 sk->sk_userlocks = val | (sk->sk_userlocks &
04190bf8944deb7 Pavel Tikhomirov 2021-08-04 1438 ~SOCK_BUF_LOCK_MASK);
04190bf8944deb7 Pavel Tikhomirov 2021-08-04 1439 break;
04190bf8944deb7 Pavel Tikhomirov 2021-08-04 1440
2bb2f5fb21b0486 Wei Wang 2021-09-29 1441 case SO_RESERVE_MEM:
2bb2f5fb21b0486 Wei Wang 2021-09-29 1442 {
2bb2f5fb21b0486 Wei Wang 2021-09-29 1443 int delta;
2bb2f5fb21b0486 Wei Wang 2021-09-29 1444
2bb2f5fb21b0486 Wei Wang 2021-09-29 1445 if (val < 0) {
2bb2f5fb21b0486 Wei Wang 2021-09-29 1446 ret = -EINVAL;
2bb2f5fb21b0486 Wei Wang 2021-09-29 1447 break;
2bb2f5fb21b0486 Wei Wang 2021-09-29 1448 }
2bb2f5fb21b0486 Wei Wang 2021-09-29 1449
2bb2f5fb21b0486 Wei Wang 2021-09-29 1450 delta = val - sk->sk_reserved_mem;
2bb2f5fb21b0486 Wei Wang 2021-09-29 1451 if (delta < 0)
2bb2f5fb21b0486 Wei Wang 2021-09-29 1452 sock_release_reserved_memory(sk, -delta);
2bb2f5fb21b0486 Wei Wang 2021-09-29 1453 else
2bb2f5fb21b0486 Wei Wang 2021-09-29 1454 ret = sock_reserve_memory(sk, delta);
2bb2f5fb21b0486 Wei Wang 2021-09-29 1455 break;
2bb2f5fb21b0486 Wei Wang 2021-09-29 1456 }
2bb2f5fb21b0486 Wei Wang 2021-09-29 1457
26859240e4ee701 Akhmat Karakotov 2022-01-31 @1458 case SO_TXREHASH:
26859240e4ee701 Akhmat Karakotov 2022-01-31 1459 if (val < -1 || val > 1) {
26859240e4ee701 Akhmat Karakotov 2022-01-31 1460 ret = -EINVAL;
26859240e4ee701 Akhmat Karakotov 2022-01-31 1461 break;
26859240e4ee701 Akhmat Karakotov 2022-01-31 1462 }
cb6cd2cec799356 Akhmat Karakotov 2022-01-31 1463 /* Paired with READ_ONCE() in tcp_rtx_synack() */
cb6cd2cec799356 Akhmat Karakotov 2022-01-31 1464 WRITE_ONCE(sk->sk_txrehash, (u8)val);
26859240e4ee701 Akhmat Karakotov 2022-01-31 1465 break;
26859240e4ee701 Akhmat Karakotov 2022-01-31 1466
^1da177e4c3f415 Linus Torvalds 2005-04-16 1467 default:
^1da177e4c3f415 Linus Torvalds 2005-04-16 1468 ret = -ENOPROTOOPT;
^1da177e4c3f415 Linus Torvalds 2005-04-16 1469 break;
^1da177e4c3f415 Linus Torvalds 2005-04-16 1470 }
^1da177e4c3f415 Linus Torvalds 2005-04-16 1471 release_sock(sk);
^1da177e4c3f415 Linus Torvalds 2005-04-16 1472 return ret;
^1da177e4c3f415 Linus Torvalds 2005-04-16 1473 }
2a91525c20d3aae Eric Dumazet 2009-05-27 1474 EXPORT_SYMBOL(sock_setsockopt);
^1da177e4c3f415 Linus Torvalds 2005-04-16 1475
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 net-next] net: introduce SO_RCVBUFAUTO to let the rcv_buf tune automatically
2022-02-16 6:57 ` Jason Xing
@ 2022-02-16 16:56 ` Eric Dumazet
2022-02-17 2:15 ` Jason Xing
0 siblings, 1 reply; 6+ messages in thread
From: Eric Dumazet @ 2022-02-16 16:56 UTC (permalink / raw)
To: Jason Xing
Cc: David Miller, Jakub Kicinski, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Paolo Abeni, Wei Wang,
Alexander Aring, Yangbo Lu, Florian Westphal, Tonghao Zhang,
Thomas Gleixner, netdev, LKML, bpf, Jason Xing
On Tue, Feb 15, 2022 at 10:58 PM Jason Xing <kerneljasonxing@gmail.com> wrote:
> Just now, I found out that the latest kernel has merged a similar
> patch (commit 04190bf89) about three months ago.
There you go :)
>
> Is it still necessary to add another separate option to clear the
> SOCK_RCVBUF_LOCK explicitly?
What do you mean, SO_BUF_LOCK is all that is needed.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 net-next] net: introduce SO_RCVBUFAUTO to let the rcv_buf tune automatically
2022-02-16 16:56 ` Eric Dumazet
@ 2022-02-17 2:15 ` Jason Xing
0 siblings, 0 replies; 6+ messages in thread
From: Jason Xing @ 2022-02-17 2:15 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Jakub Kicinski, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Paolo Abeni, Wei Wang,
Alexander Aring, Yangbo Lu, Florian Westphal, Tonghao Zhang,
Thomas Gleixner, netdev, LKML, bpf, Jason Xing
On Thu, Feb 17, 2022 at 12:56 AM Eric Dumazet <edumazet@google.com> wrote:
>
> On Tue, Feb 15, 2022 at 10:58 PM Jason Xing <kerneljasonxing@gmail.com> wrote:
> > Just now, I found out that the latest kernel has merged a similar
> > patch (commit 04190bf89) about three months ago.
>
> There you go :)
>
> >
> > Is it still necessary to add another separate option to clear the
> > SOCK_RCVBUF_LOCK explicitly?
>
> What do you mean, SO_BUF_LOCK is all that is needed.
Yeah, I think SO_BUF_LOCK is enough and we don't have to add a new
option like SOCK_RCVBUF_LOCK as we've talked about before. Thanks,
Eric.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-02-17 2:16 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-16 5:03 [PATCH v2 net-next] net: introduce SO_RCVBUFAUTO to let the rcv_buf tune automatically kerneljasonxing
2022-02-16 6:24 ` Eric Dumazet
2022-02-16 6:57 ` Jason Xing
2022-02-16 16:56 ` Eric Dumazet
2022-02-17 2:15 ` Jason Xing
2022-02-16 8:47 ` kernel test robot
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.