Return true immediately when the last segment is processed,
without waiting for the next segment.

Signed-off-by: Pengtao He <hept.hept.hept@gmail.com>
---
 net/core/skbuff.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index ee0274417948..cc3339ab829a 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3114,6 +3114,9 @@ static bool __splice_segment(struct page *page, unsigned int poff,
 		*len -= flen;
 	} while (*len && plen);
 
+	if (!*len)
+		return true;
+
 	return false;
 }
 
-- 
2.49.0

Pengtao He wrote:
> Return true immediately when the last segment is processed,
> without waiting for the next segment.

This can use a bit more explanation. Which unnecessary wait is
avoided.

The boolean return from __skb_splice_bits has a bit odd semantics. But
is ignored by its only caller anyway.

The relevant __splice_segment that can cause an early return is in the
frags loop. But I see no waiting operation in here.

Aside from that, the commit also should target [PATCH net-next],
assuuming that this is an optimization, not a fix.

> 
> Signed-off-by: Pengtao He <hept.hept.hept@gmail.com>
> ---
>  net/core/skbuff.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index ee0274417948..cc3339ab829a 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -3114,6 +3114,9 @@ static bool __splice_segment(struct page *page, unsigned int poff,
>  		*len -= flen;
>  	} while (*len && plen);
>  
> +	if (!*len)
> +		return true;
> +
>  	return false;
>  }
>  
> -- 
> 2.49.0
>

> Pengtao He wrote:
> > Return true immediately when the last segment is processed,
> > without waiting for the next segment.
> 
> This can use a bit more explanation. Which unnecessary wait is
> avoided.
> 
> The boolean return from __skb_splice_bits has a bit odd semantics. But
> is ignored by its only caller anyway.
> 
> The relevant __splice_segment that can cause an early return is in the
> frags loop. But I see no waiting operation in here.

Sorry, I didn't express it clearly.
There is no wait operation, just avoid to walking once more
in the frags loop before return true.

> 
> Aside from that, the commit also should target [PATCH net-next],
> assuuming that this is an optimization, not a fix.

Ok, the prefix [PATCH net-next] will be used.