Re: [RFC 01/01]af_packet: Enhance network capture visibility

[chetan loke <loke.chetan@gmail.com>]

On Wed, May 25, 2011 at 7:10 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 05/25/2011 04:03 PM, chetan loke wrote:
>>
>> This patch is not complete and is intended to:
>> a) demonstrate the improvments
>> b) gather suggestions
>>
>>
>> Signed-off-by: Chetan Loke<lokec@ccs.neu.edu>
>
>> +struct tpacket3_hdr {
>> +       __u32           tp_status;
>> +       __u32           tp_len;
>> +       __u32           tp_snaplen;
>> +       __u16           tp_mac;
>> +       __u16           tp_net;
>> +       __u32           tp_sec;
>> +       __u32           tp_nsec;
>> +       __u16           tp_vlan_tci;
>> +       long            tp_next_offset;
>> +};
>
> Use fixed-size variables, like __u64 instead of 'long'.  That way,
> you have the same sized msgs on 32 and 64-bit systems.
>

Thanks Ben.


The intent is to also introduce something like

typedef struct {
		uint64_t pkt_sliced:1;
		uint64_t crc_error:1;
		uint64_t code_violation:1; /* if frame had code violation */
		uint64_t num_mpls_labels:4;
		uint64_t num_vlans:3;
		uint64_t l2_type:6;
		uint64_t l3_type:4;
		uint64_t l4_type:4;
		uint64_t l7_type:8;
		uint64_t rsvd:32;
}feature_s1;

typedef struct {
	union {
		feature_s1 f_s1;
               /* future feature goes here */
	}u1;
}feature_variants;

And then embed feature_variants in the pkt_desc.


Once we have the proposed non-static frame format in place then I am
hoping some vendor can borrow this format, enhance their capture
driver and DMA the data directly in the block. This way we can also
attempt to standardize the block-capture format on linux and make it
easier for smaller FPGA shops.


>
> Thanks,
> Ben
>

Chetan