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

[Jiayu Hu <jiayu.hu@intel.com>]

Hi Jianfeng,

On Thu, Jun 22, 2017 at 05:35:23PM +0800, Tan, Jianfeng wrote:
> Hi Jiayu,
> 
> > -----Original Message-----
> > From: Hu, Jiayu
> > Sent: Thursday, June 22, 2017 4:18 PM
> > To: Tan, Jianfeng
> > Cc: dev@dpdk.org; Ananyev, Konstantin; yliu@fridaylinux.org; Wiles, Keith;
> > Bie, Tiwei; Yao, Lei A
> > Subject: Re: [PATCH v5 2/3] lib/gro: add TCP/IPv4 GRO support
> > 
> > On Mon, Jun 19, 2017 at 11:43:20PM +0800, Tan, Jianfeng wrote:
> > >
> > >
> > > On 6/18/2017 3:21 PM, Jiayu Hu wrote:
> > > >
> > > > Each element in the flow array records the information of one flow,
> > > > which includes two parts:
> > > > - key: the criteria of the same flow. If packets have the same key
> > > >      value, they belong to the same flow.
> > > > - start_index: the index of the first incoming packet of this flow in
> > > >      the item array. With start_index, we can locate the first incoming
> > > >      packet of this flow.
> > > > Each element in the item array records one packet information. It mainly
> > > > includes two parts:
> > > > - pkt: packet address
> > > > - next_pkt_index: index of the next packet of the same flow in the item
> > > >      array. All packets of the same flow are chained by next_pkt_index.
> > > >      With next_pkt_index, we can locate all packets of the same flow
> > > >      one by one.
> > > >
> > > > 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?
> > >
> > > > 	- fragmented packets.
> > >
> > > IP fragmented? I don't think we need to check it here either. It's the
> > > application's responsibility to call librte_ip_frag firstly to reassemble
> > > IP-fragmented packets, and then call this gro library to merge TCP packets.
> > > And this procedure should be shown in an example for other users to refer.
> > 
> > If we leave this check to applications, they have to call librte_ip_frag
> > first, then call GRO library. If they call GRO library first, error
> > happens. But if GRO checks if the packet is fragmented, no error happens.
> > IMO, it's more flexible. Besides, for GRO library, to check if the packet
> > is fragmented is very simple. Just to check if DF bit is set is enough.
> > So I still think GRO library need to check it.
> 
> I would expect ip fragment is also a gro engine (might be two for ipv4 and ipv6).

The case you mentioned is that packets are TSOed and also
IP fragmented. But current GRO doesn't support this case.
If we want to add a IP engine to perform IP reassembly
and cooperate with TCP engine to handle this case, I think
it's very hard to implement in current GRO. Because the
correct processing logic to process these packets is:
perform IP reassembly on N packets --> IP reassembled
packets to perform TCP GRO. So if we want to support
this case, I would prefer to ask applications to call
librte_ip_frag first and then to call GRO library,
rather than to add this IP engine.

Besides, to support this case, we also need to assume all
inputted packets are IP reassembled. Fragments which don't
have L4 header shouldn't be inputted. How do you think?

Thanks,
Jiayu