From: Jesse Brandeburg <jesse.brandeburg@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [next PATCH S35 11/14] i40e/i40evf: Refactor receive routine
Date: Fri, 15 Apr 2016 17:10:10 -0700 [thread overview]
Message-ID: <20160415171010.00002329@unknown> (raw)
In-Reply-To: <CAKgT0UdexLp2VeNJYAbNVEai+pEGBf1pak_2kmZD-rHsYreGkQ@mail.gmail.com>
On Fri, 15 Apr 2016 12:21:24 -0700
Alexander Duyck <alexander.duyck@gmail.com> wrote:
> On Fri, Apr 15, 2016 at 11:19 AM, Jesse Brandeburg
> <jesse.brandeburg@intel.com> wrote:
> > On Fri, 15 Apr 2016 10:25:37 -0700
> > Alexander Duyck <alexander.duyck@gmail.com> wrote:
> >> If due to only the size I really think this should probably be split
> >> into two patches. One for the VF and one for the PF. That way we
> >> should only be looking at about 1000 lines of change per patch instead
> >> of 2000 which becomes a bit unwieldy. If nothing else it makes the
> >> reviews easier to read as we don't end up with a novel with review
> >> comments scattered throughout.
> >
> > Thanks for all your comments Alex, they're really useful. I can split
> > the patches into (at least) two.
> >
> > As far as the comments go, most seem to be tweaks/tuning, and unless I
> > missed it not any bugs yet (but I know the patch was huge)
> >
> > So, would it be at all reasonable to proceed with the code basically
> > unchanged except for splitting it up, if no bugs are noticed during
> > review? Then I will follow up with a cleanup series?
>
> The only big issue I saw is the RXE bit check being dropped
> completely. If you can incorporate that into the cleanup_headers
> function then I would say the rest is mostly just performance bits
> that can be cleaned up later.
>
> - Alex
Alex,
The patches will be coming from Harshitha, but in the meantime I
sent them to you after I broke them all apart and added a check for RXE.
I couldn't use cleanup_headers as it doesn't have access to the receive
descriptor, so rather than adding an argument I just put it inline.
v2:
split receive refactor patches into pieces that are smaller.
added check for RXE (receive error) bit being set in the descriptor.
Thanks again!
next prev parent reply other threads:[~2016-04-16 0:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-14 13:19 [Intel-wired-lan] [next PATCH S35 00/14] i40e/i40evf updates Harshitha Ramamurthy
2016-04-14 13:19 ` [Intel-wired-lan] [next PATCH S35 01/14] i40e: Allow RSS Hash set with less than four parameters Harshitha Ramamurthy
2016-04-14 13:19 ` [Intel-wired-lan] [next PATCH S35 02/14] i40e: Fix up 32 bit timespec references Harshitha Ramamurthy
2016-04-14 13:19 ` [Intel-wired-lan] [next PATCH S35 03/14] i40e: Add elements to fd filter compare Harshitha Ramamurthy
2016-04-14 13:19 ` [Intel-wired-lan] [next PATCH S35 04/14] i40evf: Report link speed Harshitha Ramamurthy
2016-04-14 13:19 ` [Intel-wired-lan] [next PATCH S35 05/14] i40evf: Set netdev carrier properly Harshitha Ramamurthy
2016-04-14 13:19 ` [Intel-wired-lan] [next PATCH S35 06/14] i40e: Clear mac filter count on reset Harshitha Ramamurthy
2016-04-14 13:19 ` [Intel-wired-lan] [next PATCH S35 07/14] i40evf: Enable adaptive interrupt throttling Harshitha Ramamurthy
2016-04-14 13:19 ` [Intel-wired-lan] [next PATCH S35 08/14] i40e: Add message for unsupported MFP mode Harshitha Ramamurthy
2016-04-14 13:19 ` [Intel-wired-lan] [next PATCH S35 09/14] i40e/i40evf: Rename version macro Harshitha Ramamurthy
2016-04-14 13:19 ` [Intel-wired-lan] [next PATCH S35 10/14] i40e/i40evf: Refactor tunnel interpretation Harshitha Ramamurthy
2016-04-14 13:19 ` [Intel-wired-lan] [next PATCH S35 11/14] i40e/i40evf: Refactor receive routine Harshitha Ramamurthy
2016-04-15 17:25 ` Alexander Duyck
2016-04-15 18:19 ` Jesse Brandeburg
2016-04-15 19:21 ` Alexander Duyck
2016-04-16 0:10 ` Jesse Brandeburg [this message]
2016-04-16 1:51 ` Alexander Duyck
2016-04-14 13:19 ` [Intel-wired-lan] [next PATCH S35 12/14] i40e/i40evf: Remove unused hardware receive descriptor code Harshitha Ramamurthy
2016-04-14 13:19 ` [Intel-wired-lan] [next PATCH S35 13/14] i40evf: Allocate rx buffers properly Harshitha Ramamurthy
2016-04-14 13:19 ` [Intel-wired-lan] [next PATCH S35 14/14] i40e: Test memory before ethtool alloc succeeds Harshitha Ramamurthy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160415171010.00002329@unknown \
--to=jesse.brandeburg@intel.com \
--cc=intel-wired-lan@osuosl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox