Thank you for your replies. It answered my questions.
Shay
On 1/8/2019 12:58 PM, Michael Chan wrote:
On Mon, Jan 7, 2019 at 6:00 AM Shay Agroskin wrote:
a) All segments (aggregated packets) must be of the same size (except possibly
the last one).
(This in order to know each segments size, w
On Mon, Jan 7, 2019 at 6:00 AM Shay Agroskin wrote:
> a) All segments (aggregated packets) must be of the same size (except
> possibly the last one).
> (This in order to know each segments size, when re-segmenting an aggregated
> packet)
>
> b) IP ID must be incrementing unless DF is
> (To have
From: Shay Agroskin
Date: Mon, 7 Jan 2019 14:00:33 +
> 2) While we understand that implementing GRO in HW can result in
> performance gain, is HW-GRO's singularity in its ability to
> construct packets that can be re-segmented? (as appose to LRO).
> What else is expected from HW when turning
ev-ow...@vger.kernel.org On Behalf Of
Michael Chan
Sent: Saturday, December 16, 2017 10:10 AM
To: da...@davemloft.net
Cc: netdev@vger.kernel.org; andrew.gospoda...@broadcom.com
Subject: [PATCH net-next v5 0/5] Introduce NETIF_F_GRO_HW
Introduce NETIF_F_GRO_HW feature flag and convert drivers that su
From: Michael Chan
Date: Fri, 29 Dec 2017 21:20:02 -0800
> I think the name GRO_HW is perfectly fine. It is GRO aggregation done
> in hardware, and hardware providing extra information to the driver to
> setup the SKB just like GRO. I don't know what better name to call it
> than GRO_HW.
Agree
On Fri, Dec 29, 2017 at 7:12 AM, Alexander Duyck
wrote:
> On Fri, Dec 29, 2017 at 4:43 AM, Sabrina Dubroca wrote:
>> 2017-12-22, 10:14:32 -0800, Alexander Duyck wrote:
>>> On Fri, Dec 22, 2017 at 6:57 AM, Sabrina Dubroca
>>> wrote:
>>> > IIUC, with the patches that were applied, each driver can
On Fri, Dec 29, 2017 at 4:43 AM, Sabrina Dubroca wrote:
> 2017-12-22, 10:14:32 -0800, Alexander Duyck wrote:
>> On Fri, Dec 22, 2017 at 6:57 AM, Sabrina Dubroca
>> wrote:
>> > IIUC, with the patches that were applied, each driver can define
>> > whether GRO_HW depends on GRO? From a user's persp
2017-12-22, 10:14:32 -0800, Alexander Duyck wrote:
> On Fri, Dec 22, 2017 at 6:57 AM, Sabrina Dubroca wrote:
> > IIUC, with the patches that were applied, each driver can define
> > whether GRO_HW depends on GRO? From a user's perspective, this
> > inconsistent behavior is going to be quite confus
On Fri, Dec 22, 2017 at 6:57 AM, Sabrina Dubroca wrote:
> Hello,
>
> Sorry for commenting late.
>
> 2017-12-16, 03:09:39 -0500, Michael Chan wrote:
>> Introduce NETIF_F_GRO_HW feature flag and convert drivers that support
>> hardware GRO to use the new flag.
>>
>> v5:
>> - Documentation changes re
Hello,
Sorry for commenting late.
2017-12-16, 03:09:39 -0500, Michael Chan wrote:
> Introduce NETIF_F_GRO_HW feature flag and convert drivers that support
> hardware GRO to use the new flag.
>
> v5:
> - Documentation changes requested by Alexander Duyck.
> - bnx2x changes requested by Manish Cho
On Tue, Dec 19, 2017 at 11:25:29AM -0800, Michael Chan wrote:
> On Tue, Dec 19, 2017 at 11:04 AM, Marcelo Ricardo Leitner
> wrote:
> > Can we clarify on the meaning/expectations of dev_weight? The
> > documentation currently says:
> > The maximum number of packets that kernel can handle on a NAPI
On Tue, Dec 19, 2017 at 11:04 AM, Marcelo Ricardo Leitner
wrote:
> Can we clarify on the meaning/expectations of dev_weight? The
> documentation currently says:
> The maximum number of packets that kernel can handle on a NAPI
> interrupt, it's a Per-CPU variable.
>
> I believe 'packets' here refer
From: Marcelo Ricardo Leitner
Date: Tue, 19 Dec 2017 17:04:27 -0200
> I understand that for all that matters, the hardware operations
> involved on GRO_HW are really for only 1 packet, so it would make
> sense to count it as 1. OTOH, this bump may cause additional pressure
> in other places as in
On Tue, Dec 19, 2017 at 10:50:24AM -0500, David Miller wrote:
> From: Michael Chan
> Date: Sat, 16 Dec 2017 03:09:39 -0500
>
> > Introduce NETIF_F_GRO_HW feature flag and convert drivers that support
> > hardware GRO to use the new flag.
>
> Series applied, thanks for following through with this
From: Michael Chan
Date: Sat, 16 Dec 2017 03:09:39 -0500
> Introduce NETIF_F_GRO_HW feature flag and convert drivers that support
> hardware GRO to use the new flag.
Series applied, thanks for following through with this work.
Introduce NETIF_F_GRO_HW feature flag and convert drivers that support
hardware GRO to use the new flag.
v5:
- Documentation changes requested by Alexander Duyck.
- bnx2x changes requested by Manish Chopra to enable LRO by default, and
disable GRO_HW if disable_tpa module parameter is set.
v4:
-
16 matches
Mail list logo
