[net-next,0/3] cleanup of qdisc offload function

Message

shaozhengchao Aug. 16, 2022, 2:04 a.m. UTC

Some qdiscs don't care return value of qdisc offload function, so make 
function void.

Zhengchao Shao (3):
  net: sched: make mq_offload() void
  net: sched: make prio_offload() void
  net: sched: make red_offload() void

 net/sched/sch_mq.c   | 6 +++---
 net/sched/sch_prio.c | 6 +++---
 net/sched/sch_red.c  | 6 +++---
 3 files changed, 9 insertions(+), 9 deletions(-)

Comments

Jakub Kicinski Aug. 16, 2022, 3:10 a.m. UTC | #1

On Tue, 16 Aug 2022 10:04:20 +0800 Zhengchao Shao wrote:
> Some qdiscs don't care return value of qdisc offload function, so make 
> function void.

How many of these patches do you have? Is there a goal you're working
towards? I don't think the pure return value removals are worth the
noise. They don't even save LoC:

 3 files changed, 9 insertions(+), 9 deletions(-)

shaozhengchao Aug. 16, 2022, 3:32 a.m. UTC | #2

On 2022/8/16 11:10, Jakub Kicinski wrote:
> On Tue, 16 Aug 2022 10:04:20 +0800 Zhengchao Shao wrote:
>> Some qdiscs don't care return value of qdisc offload function, so make
>> function void.
> 
> How many of these patches do you have? Is there a goal you're working
> towards? I don't think the pure return value removals are worth the
> noise. They don't even save LoC:
> 
>   3 files changed, 9 insertions(+), 9 deletions(-)
Hi Jakub.
	Thank you for your reply. Recently I've been studying the kernel code 
related to qdisc, and my goal is to understand how qdisc works. If the 
code can be optimized, I do what I can to modify the optimization. Is it 
more appropriate to add warning to the offload return value? I look 
forward to your reply. Thank you.

Zhengchao Shao

Jakub Kicinski Aug. 16, 2022, 6:13 p.m. UTC | #3

On Tue, 16 Aug 2022 11:32:03 +0800 shaozhengchao wrote:
> On 2022/8/16 11:10, Jakub Kicinski wrote:
> > On Tue, 16 Aug 2022 10:04:20 +0800 Zhengchao Shao wrote:  
> >> Some qdiscs don't care return value of qdisc offload function, so make
> >> function void.  
> > 
> > How many of these patches do you have? Is there a goal you're working
> > towards? I don't think the pure return value removals are worth the
> > noise. They don't even save LoC:
> > 
> >   3 files changed, 9 insertions(+), 9 deletions(-)  
>
> 	Thank you for your reply. Recently I've been studying the kernel code 
> related to qdisc, and my goal is to understand how qdisc works. If the 
> code can be optimized, I do what I can to modify the optimization. Is it 
> more appropriate to add warning to the offload return value? I look 
> forward to your reply. Thank you.

Understood. Please stop sending the cleanups removing return values
unless the patches materially improve the code.

Jamal Hadi Salim Aug. 17, 2022, 1:19 p.m. UTC | #4

On Tue, Aug 16, 2022 at 2:13 PM Jakub Kicinski <[e-mail]> wrote:
>
> On Tue, 16 Aug 2022 11:32:03 +0800 shaozhengchao wrote:
> > On 2022/8/16 11:10, Jakub Kicinski wrote:
> > > On Tue, 16 Aug 2022 10:04:20 +0800 Zhengchao Shao wrote:
> > >> Some qdiscs don't care return value of qdisc offload function, so make
> > >> function void.
> > >
> > > How many of these patches do you have? Is there a goal you're working
> > > towards? I don't think the pure return value removals are worth the
> > > noise. They don't even save LoC:
> > >
> > >   3 files changed, 9 insertions(+), 9 deletions(-)
> >
> >       Thank you for your reply. Recently I've been studying the kernel code
> > related to qdisc, and my goal is to understand how qdisc works. If the
> > code can be optimized, I do what I can to modify the optimization. Is it
> > more appropriate to add warning to the offload return value? I look
> > forward to your reply. Thank you.
>
> Understood. Please stop sending the cleanups removing return values
> unless the patches materially improve the code.

Quoting appropriate here.
+1

cheers,
jamal