The object that is in the data-path to perform the check. More...

Collaboration diagram for protocol_port_range_dpo_t_:

Public Member Functions
	CLIB_CACHE_LINE_ALIGN_MARK (cacheline0)
	Required for pool_get_aligned. More...

Data Fields
u16	n_used_blocks
	The number of blocks from the 'block' array below that have rnages configured. More...

u16	n_free_ranges
	The total number of free ranges from all blocks. More...

protocol_port_range_t	blocks [N_BLOCKS_PER_DPO]
	the fixed size array of ranges More...

Detailed Description

The object that is in the data-path to perform the check.

Some trade-offs here; memory vs performance.

performance: the principle factor is d-cache line misses/hits. so we want the data layout to minimise the d-cache misses. This means not following dependent reads. i.e. not doing

struct B { u16 n_ranges; range_t *ragnes; // vector of ranges. }

so to read ranges[0] we would first d-cache miss on the address of the object of type B, for which we would need to wait before we can get the address of B->ranges. So this layout is better:

struct B { u16 n_ranges; range_t ragnes[N]; }

memory: the latter layout above is more memory hungry. And N needs to be: 1 - sized for the maximum required 2 - fixed, so that objects of type B can be pool allocated and so 'get'-able using an index. An option over fixed might be to allocate contiguous chunk from the pool (like we used to do for multi-path adjs).

Definition at line 102 of file ip_source_and_port_range_check.h.