archive mirror
 help / color / mirror / Atom feed
From: Dave Watson <>
To: Dominique Martinet <>
Cc: Doron Roberts-Kedes <>,
	Tom Herbert <>,
	"David S. Miller" <>, <>,
Subject: Re: [PATCH] strparser: remove any offset before parsing messages
Date: Wed, 22 Aug 2018 11:38:52 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20180822054707.GA13455@nautica>

On 08/22/18 07:47 AM, Dominique Martinet wrote:
> > > As I wrote above, I think it should not be possible, so we're not
> > > even talking about a small percentage here.
> > > The reason I didn't use skb_pull (the head-only variant) is that I'd
> > > rather have the overhead than a BUG() if I'm wrong on this...
> > 
> > A printk in that section when (orig_offset + eaten > skb_headlen(head)) 
> > confirms that this case is not uncommon or impossible. Would have to do
> > more work to see how many hundreds of times per second, but it is not a
> > philosophical concern.
> Hmm, right, it does happen if I force two bigger packets in a single
> write() on my reproducer; I guess my workload didn't exhibit that
> behaviour with a 9p client...
> I've tried measuring that overhead as well by writing a more complex bpf
> program that would fetch the offset in the skb but for some reason I'm
> reading a 0 offset when it's not zero... well, not like there's much
> choice for this at this point anyway; I don't think we'll do this
> without pull, I'll put that on background.

For what it is worth we checked the offset in bpf, something
along the lines of
struct kcm_rx_msg {   int full_len;  int offset;};
static inline struct kcm_rx_msg *kcm_rx_msg(struct __sk_buff *skb)
      { return (struct kcm_rx_msg *)skb->cb;}

int decode_framing(struct __sk_buff *skb)
{ return load_word(skb, kcm_rx_msg(skb)->offset);}

Although it did puzzle me for a while figuring that out when I ran in
to it.

  reply	other threads:[~2018-08-22 18:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-09 22:40 [PATCH v0] strparser: remove any offset before parsing messages Dominique Martinet
2018-08-21 12:51 ` [PATCH] " Dominique Martinet
2018-08-21 14:53   ` Doron Roberts-Kedes
2018-08-21 19:36     ` Dominique Martinet
2018-08-21 21:15       ` Doron Roberts-Kedes
2018-08-21 22:51         ` Dominique Martinet
2018-08-21 23:35           ` Doron Roberts-Kedes
2018-08-22  0:46             ` Dominique Martinet
2018-08-22  2:33               ` Doron Roberts-Kedes
2018-08-22  5:47                 ` Dominique Martinet
2018-08-22 18:38                   ` Dave Watson [this message]
2018-08-23  1:04                     ` Dominique Martinet

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \

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