All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dominique Martinet <asmadeus@codewreck.org>
To: Doron Roberts-Kedes <doronrk@fb.com>
Cc: Tom Herbert <tom@quantonium.net>,
	Dave Watson <davejwatson@fb.com>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] strparser: remove any offset before parsing messages
Date: Tue, 21 Aug 2018 21:36:55 +0200	[thread overview]
Message-ID: <20180821193655.GA15354@nautica> (raw)
In-Reply-To: <20180821145321.GA44710@doronrk-mbp>

Doron Roberts-Kedes wrote on Tue, Aug 21, 2018:
> There are a few issues with this patch. First, it seems like you're
> trying to fix bugs in users of strparser by changing an implementation
> detail of strparser.

Yes, that's why I have been writing since the original discussion that I
do not like this fix, but as I said in the other thread and v0 of this
patch I do not know how to tell the bpf function to start with an offset
in the skb in e.g. kcm_parse_func_strparser

I could add the pull in that function, but that feels a bit wrong on a
separation level to me.

> Second, this implementation change can add malloc's and copies where
> there were none before.

Yes I agree this is more than suboptimal for tls, I've also said that.


> If strparser users do not handle non-zero offset properly, then that
> doesn't motivate changing the implementation of strparser to copy
> around data to accomodate those buggy users. 
>
> Why not submit a patch that handles offset properly in the code you
> pointed out? 

One of the solutions I had suggested was adding a flag at strparser
setup time to only do that pull for users which cannot handle offset,
but nobody seemed interested two weeks ago. I can still do that.

That's still suboptimal, but I don't have any better idea.
To properly fix the users, I'd really need help with how bpf works to
even know if passing an offset would be possible in the first place, as
I do not see how at this time.


Thanks,
-- 
Dominique Martinet

  reply	other threads:[~2018-08-21 19:37 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 [this message]
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
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:
  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=20180821193655.GA15354@nautica \
    --to=asmadeus@codewreck.org \
    --cc=davejwatson@fb.com \
    --cc=davem@davemloft.net \
    --cc=doronrk@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=tom@quantonium.net \
    /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.