From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: Tony Nguyen <anthony.l.nguyen@intel.com>,
intel-wired-lan@lists.osuosl.org
Cc: kurt@linutronix.de, vladimir.oltean@nxp.com
Subject: Re: [Intel-wired-lan] [PATCH iwl v1 0/5] igc: TX timestamping fixes
Date: Mon, 08 May 2023 15:18:48 -0700 [thread overview]
Message-ID: <87y1lytqk7.fsf@intel.com> (raw)
In-Reply-To: <970e057f-eed9-69ae-b321-ff78049e33ac@intel.com>
Tony Nguyen <anthony.l.nguyen@intel.com> writes:
> On 5/4/2023 4:52 PM, Vinicius Costa Gomes wrote:
>> Hi,
>>
>> Changes from the "for-next-queue" version:
>> - As this is intended for the iwl/net-queue tree, removed adding
>> support for adding the "extra" tstamp registers;
>> - Added "Fixes:" tags to the appropriate patches (Vladimir Oltean);
>
> In most cases, net patches should have Fixes: tags to them. Patches 3
> and 5 don't have them and it seems like it would be applicable to them.
>
Patch 3 is directly related to patch 1, but I think it deserved a
separate commit, as it has a bit of refactor. I can squash it into patch
1, if you think it's better I can do that, no worries, I was only afraid
to make the patch harder to follow.
Patch 5, as a hardware issue workaround, I didn't know if adding a
'Fixes:' tag made sense, but as a way to direct patches to the right
stable trees, that would be a good point in favor, even if it's not
fixing a bug in the code. Is this what you had in mind? If so, I can do
that.
> Patch 4 seems more like an improvement than a bug fix? If so, -next
> would seem a better path for that patch. Based on the 'for-next-queue
> version' link, there are still some patches remaining that will go
> through -next? Perhaps this can go with them.
>
On a very loaded system, for example, time synchronization can fail if
something blocks the system workqueue from running, so in a sense, that
patches fixes/helps some user visible issues. But I can see it both
ways, that this is an improvement. What's your preference?
>> - Improved the check to catch the case that the skb has the
>> SKBTX_HW_TSTAMP flag, but TX timestamping is not enabled (Vladimir
>> Oltean);
>> - Ony check for timestamping timeouts if TX timestamping is enabled
>> (Vladimir Oltean);
>>
>> for-next-queue version link:
>> https://lore.kernel.org/intel-wired-lan/20230228054534.1093483-1-vinicius.gomes@intel.com/
>
> ...
>
>> BTW: I hope this is the correct usage of the "iwl" subject prefix.
>
> If you could also add -net|-next for the (eventual) target tree
> i.e.
> net : iwl-net
> net-next : iwl-next
>
> in this case 'iwl-net'
Yeah, I sent this patch a couple minutes before seeing the email about
the subject prefix conventions. Will use the correct one next time.
>
> Thanks,
> Tony
--
Vinicius
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
next prev parent reply other threads:[~2023-05-08 22:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-04 23:52 [Intel-wired-lan] [PATCH iwl v1 0/5] igc: TX timestamping fixes Vinicius Costa Gomes
2023-05-04 23:52 ` [Intel-wired-lan] [PATCH iwl v1 1/5] igc: Fix marking some timestamps as skipped wrongly Vinicius Costa Gomes
2023-05-05 9:49 ` Kurt Kanzenbach
2023-05-04 23:52 ` [Intel-wired-lan] [PATCH iwl v1 2/5] igc: Fix race condition in PTP tx code Vinicius Costa Gomes
2023-05-05 9:51 ` Kurt Kanzenbach
2023-05-04 23:52 ` [Intel-wired-lan] [PATCH iwl v1 3/5] igc: Fix checking for tstamp timeouts TX tstamp is off Vinicius Costa Gomes
2023-05-05 9:51 ` Kurt Kanzenbach
2023-05-04 23:52 ` [Intel-wired-lan] [PATCH iwl v1 4/5] igc: Retrieve TX timestamp during interrupt handling Vinicius Costa Gomes
2023-05-05 9:51 ` Kurt Kanzenbach
2023-05-04 23:52 ` [Intel-wired-lan] [PATCH iwl v1 5/5] igc: Add workaround for missing timestamps Vinicius Costa Gomes
2023-05-08 20:55 ` [Intel-wired-lan] [PATCH iwl v1 0/5] igc: TX timestamping fixes Tony Nguyen
2023-05-08 22:18 ` Vinicius Costa Gomes [this message]
2023-05-09 17:23 ` Tony Nguyen
2023-05-09 20:51 ` Vinicius Costa Gomes
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=87y1lytqk7.fsf@intel.com \
--to=vinicius.gomes@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kurt@linutronix.de \
--cc=vladimir.oltean@nxp.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.