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 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.