[dpdk-dev] [PATCH v5 2/3] lib/gro: add TCP/IPv4 GRO support

Stephen Hemminger stephen at networkplumber.org
Wed Jun 21 01:55:15 CEST 2017


On Wed, 21 Jun 2017 07:30:08 +0800
"Tan, Jianfeng" <jianfeng.tan at intel.com> wrote:

> >>> To process an incoming packet, we need three steps:
> >>> a. check if the packet should be processed. Packets with the following
> >>>       properties won't be processed:
> >>> 	- packets without data;
> >>> 	- packets with wrong checksums;  
> >> Why do we care to check this kind of error? Can we just suppose the
> >> applications have already dropped the packets with wrong cksum?  
> > Indeed, if we assume all inputted packets are correct, we can avoid
> > checksum checking overhead. But as a library, I think a more flexible
> > way is to enable applications to tell GRO API if checksum checking
> > is needed. For example, we can add a flag to struct rte_gro_tbl
> > and struct rte_gro_param, which indicates if the checksum checking
> > is needed. If applications set this flag, reassembly function won't
> > check packet checksum. Otherwise, we check the checksum. How do you
> > think?  
> 
> My opinion is to keep the library focusing on what it does, and make 
> clear its dependency. This flag thing will differ for different GRO 
> engines, which makes it a little complicated to me.

As long as it is documented behavior. GIGO is fine.
IMHO a well designed library does as little as possible and nothing more.


More information about the dev mailing list