* test_progs packed...
@ 2017-04-24 23:06 David Miller
2017-04-24 23:16 ` Alexei Starovoitov
0 siblings, 1 reply; 2+ messages in thread
From: David Miller @ 2017-04-24 23:06 UTC (permalink / raw)
To: ast; +Cc: daniel, kafai, netdev
Alexei, why the packed attribute usage in test_progs.c?
There should be no reason for this and it results in the object(s)
having odd addresses (and thus be unaligned) on sparc.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: test_progs packed...
2017-04-24 23:06 test_progs packed David Miller
@ 2017-04-24 23:16 ` Alexei Starovoitov
0 siblings, 0 replies; 2+ messages in thread
From: Alexei Starovoitov @ 2017-04-24 23:16 UTC (permalink / raw)
To: David Miller; +Cc: daniel, kafai, netdev
On 4/24/17 4:06 PM, David Miller wrote:
>
> Alexei, why the packed attribute usage in test_progs.c?
>
> There should be no reason for this and it results in the object(s)
> having odd addresses (and thus be unaligned) on sparc.
because in:
static struct {
struct ethhdr eth;
struct iphdr iph;
struct tcphdr tcp;
} __packed pkt_v4 = {
iph is 4 byte aligned and eth is 2-byte.
We can add 2 byte hole in front of eth, but it's ugly since clean:
bpf_prog_test_run(prog_fd, 100000, &pkt_v4, sizeof(pkt_v4),
would need to deal with this extra padding explicitly.
It's only a user space thing and not in critical path,
so inefficient loads shouldn't be a problem.
You're bringing a good point that bpf_prog_test_run_skb() on
the kernel side should probably do:
skb_reserve(skb, NET_SKB_PAD + NET_IP_ALIGN);
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2017-04-24 23:17 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-04-24 23:06 test_progs packed David Miller
2017-04-24 23:16 ` Alexei Starovoitov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox