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

[Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>]

> 
> At 2022-07-25 23:42:06, "Stephen Hemminger" <stephen@networkplumber.org> wrote:
>>On Sun, 24 Jul 2022 16:10:03 +0800
>>Huichao Cai <chcchc88@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.

I think checks are not that expensive.
My guess - actual copying will be the main cycles eater here.
Though if percentage of packets that need to be fragmented is tiny,
might be it is still worth it.
Though yes, I still think better would be not to use MBUF_FAST_FREE at 
all, but we are where we are.


> 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