[Acked] [PATCH] [Vivid][SRU] hv_netvsc: Clean up two unused variables
Brad Figg
brad.figg at canonical.com
Wed Dec 16 18:11:28 UTC 2015
On Thu, Dec 10, 2015 at 11:08:22AM -0800, Jay Vosburgh wrote:
> Andy Whitcroft <apw at canonical.com> wrote:
>
> >On Mon, Dec 07, 2015 at 05:07:35PM +0000, Andy Whitcroft wrote:
> >> On Fri, Dec 04, 2015 at 06:56:08AM -0700, Tim Gardner wrote:
> >> > On 12/04/2015 05:02 AM, Andy Whitcroft wrote:
> >> > > On Fri, Dec 04, 2015 at 12:19:09PM +0900, Seyeong Kim wrote:
> >> > >> From: Haiyang Zhang <haiyangz at microsoft.com>
> >> > >>
> >> > >> BugLink: http://bugs.launchpad.net/bugs/1521053
> >> > >>
> >> > >> The commit
> >> > >>
> >> > >> hv_netvsc: Clean up two unused variables
> >> > >
> >> > > As this commit only removes unused variables, it is not at all clear how
> >> > > this could cause or fix network slowdowns. The net effect is to remove
> >> > > 64 bytes from one structure, but this seems unlikely enough to cause
> >> > > significant performance issues.
> >> > >
> >> > > How was it determined that this was the fix?
> >> > >
> >> > > -apw
> >> >
> >> > I'm with Andy on this one. How does this really fix the problem ?
> >>
> >> It is sounding like this does actually fix something. For that to be
> >> true this layout change would need to radically affect cache
> >> performance. But if the testing can be confirmed then it has my ack.
> >>
> >> Acked-by: Andy Whitcroft <apw at canonical.com>
> >
> >Confirmed that removing these four bytes reduce the header size such
> >that it fits into the standard packet headroom and we no longer have to
> >copy the packet headers every time.
>
> We also would like to request that this patch be applied as an
> SRU for the Wily kernel as well to avoid regression during upgrades.
>
> -J
Wily already contains this commit.
>
> ---
> -Jay Vosburgh, jay.vosburgh at canonical.com
>
> --
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team
Brad
--
Brad Figg brad.figg at canonical.com http://www.canonical.com
More information about the kernel-team
mailing list