From: Jarek Poplawski <jarkao2@gmail.com>
To: Octavian Purdila <opurdila@ixiacom.com>
Cc: netdev@vger.kernel.org
Subject: Re: [RESEND] [PATCH] tcp: fix for splice receive when used with software LRO
Date: Sun, 22 Jun 2008 23:07:47 +0200 [thread overview]
Message-ID: <20080622210747.GA17472@ami.dom.local> (raw)
In-Reply-To: <200806202344.12771.opurdila@ixiacom.com>
On Fri, Jun 20, 2008 at 11:44:12PM +0300, Octavian Purdila wrote:
...
> OK, here is my attempt at making it a bit more readable:
>
> - move all of the details on offsets, lengths and buffers into a
> single function instead of doing these operation from multiple places
>
> - use a bottom up approach - try to avoid details in the high level functions,
> introduce them gradually as you go deeper in the function call stack
>
> I've attached both the patch and a full excerpt - it might be easier to
> comment on it this way.
>
> I've minimally tested the patch, no obvious functional or performance problems
> were found.
IMHO it's really more readable, and probably should be sometimes faster
if these divisions are optimized by a compiler. So, since the work is
done anyway, you could try to submit this - you got nothing to lose.
But, I think it's better to separate the change of functionality (a
recursive processing of frag_list) to another patch (if there is a
practical reason for this).
A few of my doubts below as //?? comments.
Regards,
Jarek P.
static inline void __segment_seek(struct page **page, int *poff, int *plen,
int off)
//?? unsigned ints (especially *poff for "/,%" optimization)?
{
*poff += off;
*page += *poff / PAGE_SIZE;
*poff = *poff % PAGE_SIZE;
*plen -= off;
}
static inline int __splice_segment(struct page *page, unsigned int poff,
unsigned int plen, unsigned int *off,
unsigned int *len, struct sk_buff *skb,
struct splice_pipe_desc *spd)
{
//?? if (!*len)
//?? return 1;
/* skip this segment if already processed */
if (*off >= plen) {
*off -= plen;
return 0;
}
/* ignore any bits we already processed */
if (*off) {
__segment_seek(&page, &poff, &plen, *off);
*off = 0;
}
do {
unsigned int flen = min(*len, plen);
//?? needed for a linear region?:
//?? flen = min_t(unsigned int, flen, PAGE_SIZE - poff);
if (spd_fill_page(spd, page, flen, poff, skb))
return 1;
__segment_seek(&page, &poff, &plen, flen);
*len -= flen;
} while (*len && plen);
return 0;
}
//?? The original comment with fixed "Returns..." (unless changed to void)?
int __skb_splice_bits(struct sk_buff *skb, unsigned int *offset,
unsigned int *len,
struct splice_pipe_desc *spd)
{
int seg;
/*
* map the linear part
*/
if (__splice_segment(virt_to_page(skb->data),
(unsigned long) skb->data & (PAGE_SIZE - 1),
skb_headlen(skb),
offset, len, skb, spd))
return 1;
/*
* then map the fragments
*/
for (seg = 0; seg < skb_shinfo(skb)->nr_frags; seg++) {
const skb_frag_t *f = &skb_shinfo(skb)->frags[seg];
if (__splice_segment(f->page, f->page_offset, f->size,
offset, len, skb, spd))
return 1;
}
//?? I'm not sure this recursion is really needed here, so I'd prefer
//?? to move this back to skb_splice_bits() for now, and maybe to
//?? propose this change as a separate patch giving the reasons for this.
/*
* now see if we have a frag_list to map
*/
if (skb_shinfo(skb)->frag_list) {
struct sk_buff *list = skb_shinfo(skb)->frag_list;
for (; list && *len; list = list->next)
if (__skb_splice_bits(list, offset, len, spd))
return 1;
}
return 0;
}
...
next prev parent reply other threads:[~2008-06-22 21:07 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <485B4ADE.8070102@domat.com.pl>
2008-06-18 16:07 ` [RESEND] [PATCH] tcp: fix for splice receive when used with software LRO Octavian Purdila
2008-06-20 6:37 ` Jarek Poplawski
2008-06-20 10:09 ` Octavian Purdila
2008-06-20 11:01 ` Jarek Poplawski
2008-06-20 12:39 ` Octavian Purdila
2008-06-20 13:01 ` Jarek Poplawski
2008-06-20 20:44 ` Octavian Purdila
2008-06-22 21:07 ` Jarek Poplawski [this message]
2008-06-23 9:50 ` Octavian Purdila
2008-06-23 20:48 ` Jarek Poplawski
2008-06-20 21:57 ` Jarek Poplawski
2008-06-21 0:40 ` Octavian Purdila
2008-06-21 8:39 ` Jarek Poplawski
2008-06-21 10:32 ` Octavian Purdila
2008-06-28 0:27 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080622210747.GA17472@ami.dom.local \
--to=jarkao2@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=opurdila@ixiacom.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).