Sum QoS in DPDK

Hi,
How is it possible to sum up all the QoS that was given by table match?

control ingress(
	inout my_ingress_headers_t hdr,
	inout my_ingress_metadata_t meta,
	in psa_ingress_input_metadata_t ig_intr_md,
	inout psa_ingress_output_metadata_t ostd
)
{
	/*
	 * If got match -> egress
	 * to port 1 else drop
	 */
	action send(PortId_t port, ClassOfService_t class) {
		ostd.egress_port = (PortId_t) port;
		ostd.drop = false;
		ostd.class_of_service = (ClassOfService_t) class;
	}

	/* This is workaround due to probably p4c-dpdk bug.
	 * Details can be see here:
	 * https://github.com/p4lang/p4c/issues/3861
	 * This line need to be "ostd.drop = true;"
	 */
	action drop() {
		ostd.drop = true;
	}
	
	action set_port_and_src_mac( PortId_t port,
								 ethernet_addr_t src_mac,
								 ethernet_addr_t dst_mac) {
	send_to_port(ostd, port);
		hdr.ethernet.src_addr = src_mac;
		hdr.ethernet.dst_addr = dst_mac;
	}

	table ipv4_host {
		key = { hdr.ipv4.dst_addr : exact; }
		actions = {
			send;drop;
			@defaultonly NoAction;
		}

		const default_action = NoAction();

		size = IPV4_HOST_SIZE;
	}

	/*
	 * https://p4.org/p4-spec/docs/PSA.html#sec-registers
	 * registers, counter
	 */
	apply {
				ipv4_host.apply();
	}
}

I just want to be able to know what is the “weight” that my buffer when i trig the pipeline stat from CLI.

do I need to do it from DPDK app .c code?

thanks
GUY

Are you familiar with the Register extern object defined in the PSA architecture? It is effectively an array of elements of identical type, with the distinguishing feature that you can read an element at an index, calculate a new value with arbitrary P4 code, then write the new value back, all while processing a single packet. And that is for a single instance of the Register extern. You can instantiate multiple instances, and do similar (or wildly different) things with each instance.

The Counter extern lets you count number of packets, and/or number of bytes of packets (adding their packet length), but you can only read these counter values from the control plane software, not from inside your P4 program. This may seem like an odd restriction to a P4 developer, but having it covers the vast majority of use cases of what you want packet and byte counters for in data plane programs, and making the values unreadable from inside of your P4 program opens up many additional hardware design choices that are cheaper than if the counters were readable from inside the P4 program.