All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Alexei Starovoitov <ast@kernel.org>
Subject: Re: eBPF - little-endian load instructions?
Date: Thu, 13 Apr 2017 07:58:45 +0200	[thread overview]
Message-ID: <1492063125.19193.1.camel@sipsolutions.net> (raw)
In-Reply-To: <20170413030818.GA42879@ast-mbp.thefacebook.com> (sfid-20170413_050826_067766_04CFF6B3)

On Wed, 2017-04-12 at 20:08 -0700, Alexei Starovoitov wrote:

> it's really llvm bug that i need fix. It's plain broken
> to generate what effectively is nop insn for march=bpfeb
> My only excuse that when that code was written llvm had only
> march=bpfel.
> bpfeb was added much later.

So I'm confused now. Is bpf intended to be endian-independent or not?
It sounded at first like it was, even if I have a hard time imagining
how that would even work.

> > 	#define be32_to_cpu bswap32
> > or
> > 	#define be32_to_cpu(x) (x)
> > depending on the build architecture, I guess.
> 
> yeah. that's what we should have in bpf_helpers.h

But that sounds more like it isn't.

> ntoh is enough for any networking code,
> so I guess we can live without real bswap insn.

Well, my reason for asking this is that wireless actually as a little-
endian wire protocol, unlike other network stuff :)
(Even at a bit level it's defined to transfer the LSB first, but that
doesn't really get visible at the level of the CPU that can only
address bytes.)

johannes

  reply	other threads:[~2017-04-13  5:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-11 10:38 eBPF - little-endian load instructions? Johannes Berg
2017-04-11 11:06 ` Daniel Borkmann
2017-04-11 11:15   ` Johannes Berg
2017-04-11 11:22     ` Daniel Borkmann
2017-04-11 11:26       ` Johannes Berg
2017-04-12 13:02   ` Johannes Berg
2017-04-12 16:58     ` Alexei Starovoitov
2017-04-12 19:38       ` Johannes Berg
2017-04-13  3:08         ` Alexei Starovoitov
2017-04-13  5:58           ` Johannes Berg [this message]
2017-04-14 18:42             ` Alexei Starovoitov
2017-04-15  7:06               ` Johannes Berg

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=1492063125.19193.1.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=netdev@vger.kernel.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.