[PATCH v6] ip_frag: add IPv4 fragment copy packet API

Huichao Cai chcchc88 at 163.com
Tue Jul 26 03:22:18 CEST 2022




















At 2022-07-25 23:42:06, "Stephen Hemminger" <stephen at networkplumber.org> wrote:
>On Sun, 24 Jul 2022 16:10:03 +0800
>Huichao Cai <chcchc88 at 163.com> wrote:
>
>> +
>> +	/*
>> +	 * Formal parameter checking.
>> +	 */
>> +	if (unlikely(pkt_in == NULL) || unlikely(pkts_out == NULL) ||
>> +	    unlikely(nb_pkts_out == 0) || unlikely(pool_direct == NULL) ||
>> +	    unlikely(mtu_size < RTE_ETHER_MIN_MTU))
>> +		return -EINVAL;
>> +
>> +	in_hdr = rte_pktmbuf_mtod(pkt_in, struct rte_ipv4_hdr *);
>> +	header_len = (in_hdr->version_ihl & RTE_IPV4_HDR_IHL_MASK) *
>> +	    RTE_IPV4_IHL_MULTIPLIER;
>> +
>> +	/* Check IP header length */
>> +	if (unlikely(pkt_in->data_len < header_len) ||
>> +	    unlikely(mtu_size < header_len))
>> +		return -EINVAL;
>> +
>
>My suspicions are all this input parameter checking probably costs more

>than any performance gain of having a non-segmented fast path.
These checks are consistent with the rte_ipv4_fragment_packet function.
I think these have been tested for performance.If these checks do affect performance, 
perhaps the legitimacy of the variable is better guaranteed by the caller
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/dev/attachments/20220726/e1a959d7/attachment-0001.htm>


More information about the dev mailing list