Linux Container Development
 help / color / mirror / Atom feed
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

  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