Skip to contentSkip to conversation

IP ID check (flush_id) in inet_gro_receive is necessary or not？

DISCUSSION Tan Xiaojun 2 participants 3 messages Jun 28, 2016

Subsystems (2)
Networking Network drivers
lore
Share & tools
lore

Tan Xiaojun

author
#0 lore raw

Hi everyone,

I'm sorry to bother you. But I was confused.

The IP ID check (flush_id) in inet_gro_receive is only used by tcp_gro_receive, and in tcp_gro_receive we have tcphdr check to ensure the order of skbs, like below:

flush |= (__force int)(th->ack_seq ^ th2->ack_seq); flush |= (ntohl(th2->seq) + skb_gro_len(p)) ^ ntohl(th->seq);

So if I remove the IP ID check in inet_gro_receive, there will be a problem ? And under what circumstances ?

Thanks.
Xiaojun.

#1 lore raw
Quoted 7 lines · Tan Xiaojun

Hi everyone,

I'm sorry to bother you. But I was confused.

The IP ID check (flush_id) in inet_gro_receive is only used by
tcp_gro_receive, and in tcp_gro_receive we have tcphdr check to ensure the order of skbs,

Quoted 7 lines
	like below:

	flush |= (__force int)(th->ack_seq ^ th2->ack_seq);
	flush |= (ntohl(th2->seq) + skb_gro_len(p)) ^ ntohl(th->seq);

	So if I remove the IP ID check in inet_gro_receive, there will be a

problem ? And under what circumstances ?

You probably missed a recent patch ?

commit 1530545ed64b42e87acb43c0c16401bd1ebae6bf

Author: Alexander Duyck <[email protected]>
Date:   Sun Apr 10 21:44:57 2016 -0400

GRO: Add support for TCP with fixed IPv4 ID field, limit tunnel IP ID values

This patch does two things.

First it allows TCP to aggregate TCP frames with a fixed IPv4 ID field. As a result we should now be able to aggregate flows that were converted from IPv6 to IPv4. In addition this allows us more flexibility for future implementations of segmentation as we may be able to use a fixed IP ID when segmenting the flow.

The second thing this does is that it places limitations on the outer IPv4 ID header in the case of tunneled frames. Specifically it forces the IP ID to be incrementing by 1 unless the DF bit is set in the outer IPv4 header. This way we can avoid creating overlapping series of IP IDs that could possibly be fragmented if the frame goes through GRO and is then resegmented via GSO.

Signed-off-by Alexander Duyck <[email protected]>
Signed-off-by David S. Miller <[email protected]>
author
#2 lore raw
Quoted 10 lines · Eric Dumazet
Quoted 9 lines · Tan Xiaojun

Hi everyone,

I'm sorry to bother you. But I was confused.

The IP ID check (flush_id) in inet_gro_receive is only used by
tcp_gro_receive, and in tcp_gro_receive we have tcphdr check to ensure the order of skbs,
like below:

Quoted 8 lines
Quoted 5 lines
	flush |= (__force int)(th->ack_seq ^ th2->ack_seq);
	flush |= (ntohl(th2->seq) + skb_gro_len(p)) ^ ntohl(th->seq);

	So if I remove the IP ID check in inet_gro_receive, there will be a

problem ? And under what circumstances ?

You probably missed a recent patch ?

Thank you very much.

Is this patch means forcing the IP ID to be incrementing by 1 is necessary in the case of using tunnel (if the IP_DF is not set in frag_off).

I have not used the tunneled frames. Do you have some examples for that ?

Xiaojun.

Quoted 28 lines

commit 1530545ed64b42e87acb43c0c16401bd1ebae6bf

Author: Alexander Duyck <[email protected]>
Date:   Sun Apr 10 21:44:57 2016 -0400

GRO: Add support for TCP with fixed IPv4 ID field, limit tunnel IP ID values

This patch does two things.

First it allows TCP to aggregate TCP frames with a fixed IPv4 ID field. As a result we should now be able to aggregate flows that were converted from IPv6 to IPv4. In addition this allows us more flexibility for future implementations of segmentation as we may be able to use a fixed IP ID when segmenting the flow.

The second thing this does is that it places limitations on the outer IPv4 ID header in the case of tunneled frames. Specifically it forces the IP ID to be incrementing by 1 unless the DF bit is set in the outer IPv4 header. This way we can avoid creating overlapping series of IP IDs that could possibly be fragmented if the frame goes through GRO and is then resegmented via GSO.

Signed-off-by Alexander Duyck <[email protected]>
Signed-off-by David S. Miller <[email protected]>

.