All of lore.kernel.org
 help / color / mirror / Atom feed
* Question: any hidden in __sk_buff
@ 2023-01-18  1:26 dongdwdw
  2023-01-18  6:24 ` dongdwdw
  2023-01-18  7:03 ` Martin KaFai Lau
  0 siblings, 2 replies; 3+ messages in thread
From: dongdwdw @ 2023-01-18  1:26 UTC (permalink / raw)
  To: bpf

Hi,


Hi Experts,

I am reading ebpf sample code recently. When I read socketx2_kern.c 
socketx2_user.c, I got a question here.

         __u64 proto = load_half(skb, 12);


I can not understand here: It means load 2 bytes from 12th bytes of skb 
address ( it is a pointer of struct__skb_buff ).

struct __sk_buff {

             __u32 len;
             __u32 pkt_type;
             __u32 mark;
             __u32 queue_mapping;
             __u32 protocol;
             __u32 vlan_present;
             __u32 vlan_tci;
             __u32 vlan_proto;

             ******

}

But I found the structure as above. So the reading start point should be 
at queue_mapping. But it actually reads protocol info here. *And I did 
found the result is protocol info*. Why?

The v*alue of pkt_type, mark, and queue_mapping are all 0.* But when to 
read starting from queue_mapping's offset, the info is about protocol. 
It is a little tricky to me. I can not understand this. From my 
pointview, the protocol info should start at 16 bytes.

Is there any background that is hidden from me? I search a lot and 
cannot find any detailed info about this. Please help explain this. 
Thanks so much.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Question: any hidden in __sk_buff
  2023-01-18  1:26 Question: any hidden in __sk_buff dongdwdw
@ 2023-01-18  6:24 ` dongdwdw
  2023-01-18  7:03 ` Martin KaFai Lau
  1 sibling, 0 replies; 3+ messages in thread
From: dongdwdw @ 2023-01-18  6:24 UTC (permalink / raw)
  To: bpf

I found the tricks here. it is BPF_LD_ABS instruction.

On 2023/1/18 09:26, dongdwdw wrote:
> Hi,
>
>
> Hi Experts,
>
> I am reading ebpf sample code recently. When I read socketx2_kern.c 
> socketx2_user.c, I got a question here.
>
>         __u64 proto = load_half(skb, 12);
>
>
> I can not understand here: It means load 2 bytes from 12th bytes of 
> skb address ( it is a pointer of struct__skb_buff ).
>
> struct __sk_buff {
>
>             __u32 len;
>             __u32 pkt_type;
>             __u32 mark;
>             __u32 queue_mapping;
>             __u32 protocol;
>             __u32 vlan_present;
>             __u32 vlan_tci;
>             __u32 vlan_proto;
>
>             ******
>
> }
>
> But I found the structure as above. So the reading start point should 
> be at queue_mapping. But it actually reads protocol info here. *And I 
> did found the result is protocol info*. Why?
>
> The v*alue of pkt_type, mark, and queue_mapping are all 0.* But when 
> to read starting from queue_mapping's offset, the info is about 
> protocol. It is a little tricky to me. I can not understand this. From 
> my pointview, the protocol info should start at 16 bytes.
>
> Is there any background that is hidden from me? I search a lot and 
> cannot find any detailed info about this. Please help explain this. 
> Thanks so much.
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Question: any hidden in __sk_buff
  2023-01-18  1:26 Question: any hidden in __sk_buff dongdwdw
  2023-01-18  6:24 ` dongdwdw
@ 2023-01-18  7:03 ` Martin KaFai Lau
  1 sibling, 0 replies; 3+ messages in thread
From: Martin KaFai Lau @ 2023-01-18  7:03 UTC (permalink / raw)
  To: dongdwdw; +Cc: bpf

On 1/17/23 5:26 PM, dongdwdw wrote:
> I am reading ebpf sample code recently. When I read socketx2_kern.c 
> socketx2_user.c, I got a question here.
> 
>          __u64 proto = load_half(skb, 12);
> 
> 
> I can not understand here: It means load 2 bytes from 12th bytes of skb address 
> ( it is a pointer of struct__skb_buff ). >
> struct __sk_buff {
> 
>              __u32 len;
>              __u32 pkt_type;
>              __u32 mark;
>              __u32 queue_mapping;
>              __u32 protocol;
>              __u32 vlan_present;
>              __u32 vlan_tci;
>              __u32 vlan_proto;
> 
>              ******
> 
> }
> 
> But I found the structure as above. So the reading start point should be at 
> queue_mapping. But it actually reads protocol info here. *And I did found the 
> result is protocol info*. Why?
> 
> The v*alue of pkt_type, mark, and queue_mapping are all 0.* But when to read 
> starting from queue_mapping's offset, the info is about protocol. It is a little 
> tricky to me. I can not understand this. From my pointview, the protocol info 
> should start at 16 bytes.
> 
> Is there any background that is hidden from me? I search a lot and cannot find 
> any detailed info about this. Please help explain this. Thanks so much.

If you search for load_half, it is defined in bpf_legacy.h:
/* Functions to emit BPF_LD_ABS and BPF_LD_IND instructions.... */

A search on ABS under Documentation/bpf leads to 
Documentation/bpf/instruction-set.rst:

~~~~ snippet ~~~~

   BPF_ABS        0x20   legacy BPF packet access (absolute)   `Legacy BPF 
Packet access instructions`_
   BPF_IND        0x40   legacy BPF packet access (indirect)   `Legacy BPF 
Packet access instructions`_

... ...

Legacy BPF Packet access instructions
-------------------------------------

eBPF previously introduced special instructions for access to packet data that 
were carried over from classic BPF. However, these instructions are deprecated 
and should no longer be used.

~~~~ snippet ~~~~

Instead of samples/bpf, tools/testing/selftests/bpf/progs is a much better place 
to look for examples. eg. The test_tc_*.c that uses skb->protocol.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-01-18  7:42 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-01-18  1:26 Question: any hidden in __sk_buff dongdwdw
2023-01-18  6:24 ` dongdwdw
2023-01-18  7:03 ` Martin KaFai Lau

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.