From: Dan Smith <danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
Cc: containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
Subject: Re: [PATCH 1/4] Unify skb read/write functions and fix for fragmented buffers
Date: Mon, 16 Nov 2009 10:51:29 -0800 [thread overview]
Message-ID: <87einyuwum.fsf@caffeine.danplanet.com> (raw)
In-Reply-To: <4B019A2C.9090507-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> (Oren Laadan's message of "Mon\, 16 Nov 2009 13\:30\:04 -0500")
>> struct ckpt_hdr_socket_buffer {
>> struct ckpt_hdr h;
>> + __u64 transport_header;
>> + __u64 network_header;
>> + __u64 mac_header;
>> + __u64 lin_len; /* Length of linear data */
>> + __u64 frg_len; /* Length of fragment data */
>> + __u64 skb_len; /* Length of skb (adjusted) */
>> + __u64 hdr_len; /* Length of skipped header */
>> + __u64 mac_len;
OL> Can you use u32 (or even less ?) for these ?
Well, in the structure the len is an unsigned int, so u64 seemed
appropriate.
>> __s32 sk_objref;
>> __s32 pr_objref;
>> + __u16 protocol;
>> + __u16 nr_frags;
>> + __u8 cb[48];
OL> Do you it will ever be required that cb[] be aligned ?
It's not aligned in the real structure and it's mostly opaque data, so
no, I wouldn't think so.
OL> I'm unsure how much of a performance issue this is - I sort of
OL> expected a comment from Dave Hansen about this; Did you consider
OL> reusing the restore_read_page() from checkpoint/memory.c ? (and
OL> the matching checkpoint_dump_page() for the checkpoint).
Nope, I'll take a look.
>> + for (i = 0; i < h->nr_frags; i++) {
OL> Sanitize h->nr_frags ?
To what? I've already checked h->frg_len at this point, so I think
maybe just making sure frag_len never crosses zero would be
sufficient.
>> + for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
>> + skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
>> + u8 *vaddr = kmap(frag->page);
OL> Here, too, consider checkpoint_dump_page() to avoid kmap() ?
OL> It makes sense to have a scratch page to be used (also) for this,
OL> on ckpt_ctx - to avoid alloc/dealloc repeatedly.
Hmm, is there an alloc/dealloc here?
I'll take a look at checkpoint_dump_page()...
--
Dan Smith
IBM Linux Technology Center
email: danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org
next prev parent reply other threads:[~2009-11-16 18:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-10 18:47 Add support for connected INET sockets Dan Smith
2009-11-10 18:47 ` [PATCH 2/4] [RFC] Add c/r support for connected INET sockets (v4) Dan Smith
2009-11-11 20:32 ` Serge E. Hallyn
[not found] ` <1257878856-25520-1-git-send-email-danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-11-10 18:47 ` [PATCH 1/4] Unify skb read/write functions and fix for fragmented buffers Dan Smith
[not found] ` <1257878856-25520-2-git-send-email-danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-11-11 20:02 ` Serge E. Hallyn
2009-11-16 18:30 ` Oren Laadan
[not found] ` <4B019A2C.9090507-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2009-11-16 18:51 ` Dan Smith [this message]
[not found] ` <87einyuwum.fsf-FLMGYpZoEPULwtHQx/6qkW3U47Q5hpJU@public.gmane.org>
2009-11-16 19:05 ` Oren Laadan
2009-11-10 18:47 ` [PATCH 3/4] Update the UNIX buffer restore code to match the new format saved in the image file Dan Smith
[not found] ` <1257878856-25520-4-git-send-email-danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-11-11 21:38 ` Serge E. Hallyn
[not found] ` <20091111213851.GE8761-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-11-11 21:57 ` Dan Smith
[not found] ` <87vdhgvi6b.fsf-FLMGYpZoEPULwtHQx/6qkW3U47Q5hpJU@public.gmane.org>
2009-11-12 2:18 ` Serge E. Hallyn
[not found] ` <20091112021824.GA14646-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-11-12 18:19 ` Dan Smith
[not found] ` <87k4xvvc5b.fsf-FLMGYpZoEPULwtHQx/6qkW3U47Q5hpJU@public.gmane.org>
2009-11-12 19:43 ` Serge E. Hallyn
2009-11-16 18:35 ` Oren Laadan
2009-11-11 21:40 ` Serge E. Hallyn
2009-11-10 18:47 ` [PATCH 4/4] Add some content to the readme.txt for socket c/r Dan Smith
2009-11-16 18:38 ` Add support for connected INET sockets Oren Laadan
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=87einyuwum.fsf@caffeine.danplanet.com \
--to=danms-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
--cc=orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org \
/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