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