History log of /dpdk/lib/gro/gro_tcp4.c (Results 1 – 9 of 9)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v24.07-rc2, v24.07-rc1, v24.03, v24.03-rc4, v24.03-rc3, v24.03-rc2, v24.03-rc1
# 547f2943 08-Jan-2024 Kumara Parameshwaran <kumaraparamesh92@gmail.com>

gro: fix reordering of packets

In the current implementation when a packet is received with
special TCP flag(s) set, only that packet is delivered out of order.
There could be already coalesced pack

gro: fix reordering of packets

In the current implementation when a packet is received with
special TCP flag(s) set, only that packet is delivered out of order.
There could be already coalesced packets in the GRO table
belonging to the same flow but not delivered.
This fix makes sure that the entire segment is delivered with the
special flag(s) set which is how the Linux GRO is also implemented.

Fixes: 0d2cbe59b719 ("lib/gro: support TCP/IPv4")
Cc: stable@dpdk.org

Signed-off-by: Kumara Parameshwaran <kumaraparamesh92@gmail.com>
Reviewed-by: Jiayu Hu <hujiayu.hu@foxmail.com>

show more ...


Revision tags: v23.11, v23.11-rc4, v23.11-rc3, v23.11-rc2, v23.11-rc1, v23.07, v23.07-rc4, v23.07-rc3
# 63a98ffe 08-Jul-2023 Stephen Hemminger <stephen@networkplumber.org>

gro: use mbuf API for offset addition

Replace explicit packet offset computations with rte_pktmbuf_mtod_offset().

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Chengwen Fe

gro: use mbuf API for offset addition

Replace explicit packet offset computations with rte_pktmbuf_mtod_offset().

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>

show more ...


Revision tags: v23.07-rc2
# 5c55e819 21-Jun-2023 Kumara Parameshwaran <kumaraparamesh92@gmail.com>

gro: refactor IPv4 to prepare for IPv6

Refactor the existing code to reuse data strutures and functions
to add support for IPv6 GRO.

Signed-off-by: Kumara Parameshwaran <kumaraparamesh92@gmail.com>

gro: refactor IPv4 to prepare for IPv6

Refactor the existing code to reuse data strutures and functions
to add support for IPv6 GRO.

Signed-off-by: Kumara Parameshwaran <kumaraparamesh92@gmail.com>
Reviewed-by: Jiayu Hu <jiayu.hu@intel.com>

show more ...


Revision tags: v23.07-rc1, v23.03, v23.03-rc4, v23.03-rc3, v23.03-rc2, v23.03-rc1, v22.11, v22.11-rc4, v22.11-rc3, v22.11-rc2
# 72f51b09 16-Oct-2022 Kumara Parameshwaran <kumaraparamesh92@gmail.com>

gro: check payload length after trim

When packet is padded with extra bytes the
the validation of the payload length should be done
after the trim operation

Fixes: b8a55871d5af ("gro: trim tail pad

gro: check payload length after trim

When packet is padded with extra bytes the
the validation of the payload length should be done
after the trim operation

Fixes: b8a55871d5af ("gro: trim tail padding bytes")
Cc: stable@dpdk.org

Signed-off-by: Kumara Parameshwaran <kumaraparamesh92@gmail.com>
Acked-by: Jiayu Hu <jiayu.hu@intel.com>

show more ...


Revision tags: v22.11-rc1
# b8a55871 27-Jul-2022 Jun Qiu <jun.qiu@jaguarmicro.com>

gro: trim tail padding bytes

Exclude CRC fields, the minimum Ethernet packet
length is 60 bytes. When the actual packet length
is less than 60 bytes, padding is added to the tail.
When GRO is perfor

gro: trim tail padding bytes

Exclude CRC fields, the minimum Ethernet packet
length is 60 bytes. When the actual packet length
is less than 60 bytes, padding is added to the tail.
When GRO is performed on a packet containing a padding
field, mbuf->pkt_len is the one that contains the
padding field, which leads to the error of thinking
of the padding field as the actual content of the packet.
We need to trim away this extra padding field during
GRO processing.

Fixes: 0d2cbe59b719 ("lib/gro: support TCP/IPv4")
Cc: stable@dpdk.org

Signed-off-by: Jun Qiu <jun.qiu@jaguarmicro.com>
Acked-by: Jiayu Hu <Jiayu.hu@intel.com>

show more ...


# bc4a7f7e 07-Sep-2022 Kumara Parameshwaran <kumaraparamesh92@gmail.com>

gro: fix chain index for more than 2 packets

When more than two packets are merged in a flow, and if we receive
a 3rd packet which is matching the sequence of the 2nd packet the
prev_idx will be 1 a

gro: fix chain index for more than 2 packets

When more than two packets are merged in a flow, and if we receive
a 3rd packet which is matching the sequence of the 2nd packet the
prev_idx will be 1 and not 2, hence resulting in packet re-ordering

Signed-off-by: Kumara Parameshwaran <kumaraparamesh92@gmail.com>
Acked-by: Jiayu Hu <jiayu.hu@intel.com>

show more ...


Revision tags: v22.07, v22.07-rc4, v22.07-rc3, v22.07-rc2, v22.07-rc1, v22.03, v22.03-rc4, v22.03-rc3, v22.03-rc2
# 30a1de10 15-Feb-2022 Sean Morrissey <sean.morrissey@intel.com>

lib: remove unneeded header includes

These header includes have been flagged by the iwyu_tool
and removed.

Signed-off-by: Sean Morrissey <sean.morrissey@intel.com>


Revision tags: v22.03-rc1, v21.11, v21.11-rc4, v21.11-rc3, v21.11-rc2, v21.11-rc1
# 04d43857 07-Oct-2021 Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>

net: rename Ethernet header fields

Definition of `rte_ether_addr` structure used a workaround allowing DPDK
and Windows SDK headers to be used in the same file, because Windows SDK
defines `s_addr`

net: rename Ethernet header fields

Definition of `rte_ether_addr` structure used a workaround allowing DPDK
and Windows SDK headers to be used in the same file, because Windows SDK
defines `s_addr` as a macro. Rename `s_addr` to `src_addr` and `d_addr`
to `dst_addr` to avoid the conflict and remove the workaround.
Deprecation notice:
https://mails.dpdk.org/archives/dev/2021-July/215270.html

Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>

show more ...


Revision tags: v21.08, v21.08-rc4, v21.08-rc3, v21.08-rc2, v21.08-rc1, v21.05, v21.05-rc4, v21.05-rc3, v21.05-rc2, v21.05-rc1
# 99a2dd95 20-Apr-2021 Bruce Richardson <bruce.richardson@intel.com>

lib: remove librte_ prefix from directory names

There is no reason for the DPDK libraries to all have 'librte_' prefix on
the directory names. This prefix makes the directory names longer and also
m

lib: remove librte_ prefix from directory names

There is no reason for the DPDK libraries to all have 'librte_' prefix on
the directory names. This prefix makes the directory names longer and also
makes it awkward to add features referring to individual libraries in the
build - should the lib names be specified with or without the prefix.
Therefore, we can just remove the library prefix and use the library's
unique name as the directory name, i.e. 'eal' rather than 'librte_eal'

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>

show more ...