Re: svn commit: r333503 - stable/11/sys/net

[Allan Jude]

On 2018-05-12 01:15, Oleksandr Tymoshenko wrote:
> Ian Lepore (i...@freebsd.org) wrote:
>> On Fri, 2018-05-11 at 19:31 -0400, Jonathan T. Looney wrote:
>>> On Fri, May 11, 2018 at 4:40 PM, Stephen Hurd  wrote:


 Author: shurd
 Date: Fri May 11 20:40:26 2018
 New Revision: 333503
 URL: https://svnweb.freebsd.org/changeset/base/333503

 Log:
   MFC r29, r66, r73

   r29: Fix off-by-one error requesting tx interrupt
   r66: Cleanup queues when iflib_device_register fails
   r73: Log iflib_tx_structures_setup failure in function

>>> Is this an acceptable style for MFC logs?
>>>
>>> I'm asking because I actually prefer this to reading (or compiling) the
>>> concatenated log messages from several changes. However, I never knew it
>>> was acceptable to summarize like this. If it is, I'd like to know so I can
>>> adopt it for run-of-the-mill MFCs.
>>>
>>> Jonathan
>>
>> This used to be my preferred format, essentially to summarize what's
>> being mfc'd. But then I started using the MFC Tracker tool [*] and it
>> automatically generates a commit message that contains the full text,
>> so I stopped trying to summarize things.
> 
> I've just deployed new mfctracker version with summarized MFC commit
> message support so users can now switch between full MFC log and a
> short version. Of course it's only useful if selected commits have
> one-line summary in the first line of a commit message.
>  
>> [*] https://mfc.kernelnomicon.org/6/
>>
>> -- Ian
> 

Thank you for building and constantly improving this extremely useful tool.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r333503 - stable/11/sys/net

[Oleksandr Tymoshenko]

Bruce Evans (b...@optusnet.com.au) wrote:
> On Fri, 11 May 2018, Ian Lepore wrote:
> 
> > On Fri, 2018-05-11 at 19:31 -0400, Jonathan T. Looney wrote:
> >> On Fri, May 11, 2018 at 4:40 PM, Stephen Hurd  wrote:
> >>>
> >>>
> >>> Author: shurd
> >>> Date: Fri May 11 20:40:26 2018
> >>> New Revision: 333503
> >>> URL: https://svnweb.freebsd.org/changeset/base/333503
> >>>
> >>> Log:
> >>> � MFC r29, r66, r73
> >>>
> >>> � r29: Fix off-by-one error requesting tx interrupt
> >>> � r66: Cleanup queues when iflib_device_register fails
> >>> � r73: Log iflib_tx_structures_setup failure in function
> >>>
> >> Is this an acceptable style for MFC logs?
> >>
> >> I'm asking because I actually prefer this to reading (or compiling) the
> >> concatenated log messages from several changes. However, I never knew it
> >> was acceptable to summarize like this. If it is, I'd like to know so I can
> >> adopt it for run-of-the-mill MFCs.
> >>
> >> Jonathan
> >
> > This used to be my preferred format, essentially to summarize what's
> > being mfc'd. But then I started using the MFC Tracker tool [*] and it
> > automatically generates a commit message that contains the full text,
> > so I stopped trying to summarize things.
> >
> > [*]�https://mfc.kernelnomicon.org/6/
> 
> It was the normal style with cvs (to avoid spamming the repository as
> well as readers).  Howver, one of many worse behaviours in svn is that
> after checking out a branch, svn log only shows history for the branch,
> so it is hard to find the full log messages even if you know that the
> visible ones are only summaries.

Although not a direct functional equivalent of CVS log command 'svn log -g'
shows logs for merged commits too

-- 
gonzo
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r333503 - stable/11/sys/net

[Oleksandr Tymoshenko]

Ian Lepore (i...@freebsd.org) wrote:
> On Fri, 2018-05-11 at 19:31 -0400, Jonathan T. Looney wrote:
> > On Fri, May 11, 2018 at 4:40 PM, Stephen Hurd  wrote:
> > > 
> > > 
> > > Author: shurd
> > > Date: Fri May 11 20:40:26 2018
> > > New Revision: 333503
> > > URL: https://svnweb.freebsd.org/changeset/base/333503
> > > 
> > > Log:
> > >   MFC r29, r66, r73
> > > 
> > >   r29: Fix off-by-one error requesting tx interrupt
> > >   r66: Cleanup queues when iflib_device_register fails
> > >   r73: Log iflib_tx_structures_setup failure in function
> > > 
> > Is this an acceptable style for MFC logs?
> > 
> > I'm asking because I actually prefer this to reading (or compiling) the
> > concatenated log messages from several changes. However, I never knew it
> > was acceptable to summarize like this. If it is, I'd like to know so I can
> > adopt it for run-of-the-mill MFCs.
> > 
> > Jonathan
> 
> This used to be my preferred format, essentially to summarize what's
> being mfc'd. But then I started using the MFC Tracker tool [*] and it
> automatically generates a commit message that contains the full text,
> so I stopped trying to summarize things.

I've just deployed new mfctracker version with summarized MFC commit
message support so users can now switch between full MFC log and a
short version. Of course it's only useful if selected commits have
one-line summary in the first line of a commit message.
 
> [*] https://mfc.kernelnomicon.org/6/
> 
> -- Ian

-- 
gonzo
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r333503 - stable/11/sys/net

[Rodney W. Grimes]

> > On Fri, 11 May 2018, Ian Lepore wrote:
> > 
> > > On Fri, 2018-05-11 at 19:31 -0400, Jonathan T. Looney wrote:
> > >> On Fri, May 11, 2018 at 4:40 PM, Stephen Hurd  wrote:
> > >>>
> > >>>
> > >>> Author: shurd
> > >>> Date: Fri May 11 20:40:26 2018
> > >>> New Revision: 333503
> > >>> URL: https://svnweb.freebsd.org/changeset/base/333503
> > >>>
> > >>> Log:
> > >>> ? MFC r29, r66, r73
> > >>>
> > >>> ? r29: Fix off-by-one error requesting tx interrupt
> > >>> ? r66: Cleanup queues when iflib_device_register fails
> > >>> ? r73: Log iflib_tx_structures_setup failure in function
> > >>>

I was actually discussing an aspect of this early today and
would like to see, if possible, the *actual* mergeinfo in
the commit mail message, and would really really like to have
it in the log, but that may not be possible.

For r54 this looks like:
Modified: svn:mergeinfo
## -0,0 +0,1 ##
   Merged 
/head:r308728,314369,315243,316026,316581,316616,318359,319922,319990,321481,323232-323233,323321,323874,323955,324323,324964,325169,325488,325620,326985,326999-327001,327003,329335

(We would want to line wrap it at 80, left untouched here)

As, IMHO, this would help to catch missing mergeinfo (caused by
svn commit not in root of branch),
and merges that are more than what they claim (usually caused
by a dirty tree before svn merge commands).

This is typically 2 lines of added info,
and it IS part of the normal output from a svn diff,
but not clear to me why this is not in the commit mail message.

> > >> Is this an acceptable style for MFC logs?
> > >>
> > >> I'm asking because I actually prefer this to reading (or compiling) the
> > >> concatenated log messages from several changes. However, I never knew it
> > >> was acceptable to summarize like this. If it is, I'd like to know so I 
> > >> can
> > >> adopt it for run-of-the-mill MFCs.
> > >>
> > >> Jonathan
> > >
> > > This used to be my preferred format, essentially to summarize what's
> > > being mfc'd. But then I started using the MFC Tracker tool [*] and it
> > > automatically generates a commit message that contains the full text,
> > > so I stopped trying to summarize things.
> > >
> > > [*]?https://mfc.kernelnomicon.org/6/
> > 
> > It was the normal style with cvs (to avoid spamming the repository as
> > well as readers).  Howver, one of many worse behaviours in svn is that
> > after checking out a branch, svn log only shows history for the branch,
> > so it is hard to find the full log messages even if you know that the
> > visible ones are only summaries.
> 
> Though I don't care much for this behavior either you can get the
> original log entry if you get the changeset number by doing a
> svn log -c XX ^/head
> without that trailing ^/head you get a null output as that change
> does not exist on your current branch.
> 
> You can also find the changeset number if the stable/X commit log
> does not have it by looking at the tail of a
> svn diff -c XX
> which has the mergeinfo in it, if it was done correctly.
> 
> For this commit it would be
> svn diff -c 333503 | tail
> 
> > Bruce
> 
> -- 
> Rod Grimes rgri...@freebsd.org
> 
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r333503 - stable/11/sys/net

[John Baldwin]

On Friday, May 11, 2018 07:31:40 PM Jonathan T. Looney wrote:
> On Fri, May 11, 2018 at 4:40 PM, Stephen Hurd  wrote:
> >
> > Author: shurd
> > Date: Fri May 11 20:40:26 2018
> > New Revision: 333503
> > URL: https://svnweb.freebsd.org/changeset/base/333503
> >
> > Log:
> >   MFC r29, r66, r73
> >
> >   r29: Fix off-by-one error requesting tx interrupt
> >   r66: Cleanup queues when iflib_device_register fails
> >   r73: Log iflib_tx_structures_setup failure in function
> >
> 
> Is this an acceptable style for MFC logs?
> 
> I'm asking because I actually prefer this to reading (or compiling) the
> concatenated log messages from several changes. However, I never knew it
> was acceptable to summarize like this. If it is, I'd like to know so I can
> adopt it for run-of-the-mill MFCs.

I prefer to summarize myself, but others have complained that you then
can't grep for strings used in the head commit log to determine if a
change has been MFC'd (assuming you don't have the head rev handy and
want to search by some name / string you remember).  In particular I
preferred doing a "squash" of fixup type commits when doing MFCs, but
I've relented to doing the full logs.

-- 
John Baldwin
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r333503 - stable/11/sys/net

[Rodney W. Grimes]

> On Fri, 11 May 2018, Ian Lepore wrote:
> 
> > On Fri, 2018-05-11 at 19:31 -0400, Jonathan T. Looney wrote:
> >> On Fri, May 11, 2018 at 4:40 PM, Stephen Hurd  wrote:
> >>>
> >>>
> >>> Author: shurd
> >>> Date: Fri May 11 20:40:26 2018
> >>> New Revision: 333503
> >>> URL: https://svnweb.freebsd.org/changeset/base/333503
> >>>
> >>> Log:
> >>> ? MFC r29, r66, r73
> >>>
> >>> ? r29: Fix off-by-one error requesting tx interrupt
> >>> ? r66: Cleanup queues when iflib_device_register fails
> >>> ? r73: Log iflib_tx_structures_setup failure in function
> >>>
> >> Is this an acceptable style for MFC logs?
> >>
> >> I'm asking because I actually prefer this to reading (or compiling) the
> >> concatenated log messages from several changes. However, I never knew it
> >> was acceptable to summarize like this. If it is, I'd like to know so I can
> >> adopt it for run-of-the-mill MFCs.
> >>
> >> Jonathan
> >
> > This used to be my preferred format, essentially to summarize what's
> > being mfc'd. But then I started using the MFC Tracker tool [*] and it
> > automatically generates a commit message that contains the full text,
> > so I stopped trying to summarize things.
> >
> > [*]?https://mfc.kernelnomicon.org/6/
> 
> It was the normal style with cvs (to avoid spamming the repository as
> well as readers).  Howver, one of many worse behaviours in svn is that
> after checking out a branch, svn log only shows history for the branch,
> so it is hard to find the full log messages even if you know that the
> visible ones are only summaries.

Though I don't care much for this behavior either you can get the
original log entry if you get the changeset number by doing a
svn log -c XX ^/head
without that trailing ^/head you get a null output as that change
does not exist on your current branch.

You can also find the changeset number if the stable/X commit log
does not have it by looking at the tail of a
svn diff -c XX
which has the mergeinfo in it, if it was done correctly.

For this commit it would be
svn diff -c 333503 | tail

> Bruce

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r333503 - stable/11/sys/net

[Warner Losh]

On Fri, May 11, 2018 at 5:31 PM, Jonathan T. Looney  wrote:

> On Fri, May 11, 2018 at 4:40 PM, Stephen Hurd  wrote:
> >
> > Author: shurd
> > Date: Fri May 11 20:40:26 2018
> > New Revision: 333503
> > URL: https://svnweb.freebsd.org/changeset/base/333503
> >
> > Log:
> >   MFC r29, r66, r73
> >
> >   r29: Fix off-by-one error requesting tx interrupt
> >   r66: Cleanup queues when iflib_device_register fails
> >   r73: Log iflib_tx_structures_setup failure in function
> >
>
> Is this an acceptable style for MFC logs?
>
> I'm asking because I actually prefer this to reading (or compiling) the
> concatenated log messages from several changes. However, I never knew it
> was acceptable to summarize like this. If it is, I'd like to know so I can
> adopt it for run-of-the-mill MFCs.
>

Unless there's a compelling reason to not do it, it is totally fine. I used
to do mega-nanobsd MFCs exactly like this (though I may have include author
of original commit sometimes). In general, anything is an acceptable style
for MFC. The project hasn't set a style, and the variation between
committers is large.

Warner
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r333503 - stable/11/sys/net

[Bruce Evans]

On Fri, 11 May 2018, Ian Lepore wrote:


On Fri, 2018-05-11 at 19:31 -0400, Jonathan T. Looney wrote:

On Fri, May 11, 2018 at 4:40 PM, Stephen Hurd  wrote:



Author: shurd
Date: Fri May 11 20:40:26 2018
New Revision: 333503
URL: https://svnweb.freebsd.org/changeset/base/333503

Log:
? MFC r29, r66, r73

? r29: Fix off-by-one error requesting tx interrupt
? r66: Cleanup queues when iflib_device_register fails
? r73: Log iflib_tx_structures_setup failure in function


Is this an acceptable style for MFC logs?

I'm asking because I actually prefer this to reading (or compiling) the
concatenated log messages from several changes. However, I never knew it
was acceptable to summarize like this. If it is, I'd like to know so I can
adopt it for run-of-the-mill MFCs.

Jonathan


This used to be my preferred format, essentially to summarize what's
being mfc'd. But then I started using the MFC Tracker tool [*] and it
automatically generates a commit message that contains the full text,
so I stopped trying to summarize things.

[*]?https://mfc.kernelnomicon.org/6/


It was the normal style with cvs (to avoid spamming the repository as
well as readers).  Howver, one of many worse behaviours in svn is that
after checking out a branch, svn log only shows history for the branch,
so it is hard to find the full log messages even if you know that the
visible ones are only summaries.

Bruce___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r333503 - stable/11/sys/net

[Ian Lepore]

On Fri, 2018-05-11 at 19:31 -0400, Jonathan T. Looney wrote:
> On Fri, May 11, 2018 at 4:40 PM, Stephen Hurd  wrote:
> > 
> > 
> > Author: shurd
> > Date: Fri May 11 20:40:26 2018
> > New Revision: 333503
> > URL: https://svnweb.freebsd.org/changeset/base/333503
> > 
> > Log:
> >   MFC r29, r66, r73
> > 
> >   r29: Fix off-by-one error requesting tx interrupt
> >   r66: Cleanup queues when iflib_device_register fails
> >   r73: Log iflib_tx_structures_setup failure in function
> > 
> Is this an acceptable style for MFC logs?
> 
> I'm asking because I actually prefer this to reading (or compiling) the
> concatenated log messages from several changes. However, I never knew it
> was acceptable to summarize like this. If it is, I'd like to know so I can
> adopt it for run-of-the-mill MFCs.
> 
> Jonathan

This used to be my preferred format, essentially to summarize what's
being mfc'd. But then I started using the MFC Tracker tool [*] and it
automatically generates a commit message that contains the full text,
so I stopped trying to summarize things.

[*] https://mfc.kernelnomicon.org/6/

-- Ian

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r333503 - stable/11/sys/net

[Jonathan T. Looney]

On Fri, May 11, 2018 at 4:40 PM, Stephen Hurd  wrote:
>
> Author: shurd
> Date: Fri May 11 20:40:26 2018
> New Revision: 333503
> URL: https://svnweb.freebsd.org/changeset/base/333503
>
> Log:
>   MFC r29, r66, r73
>
>   r29: Fix off-by-one error requesting tx interrupt
>   r66: Cleanup queues when iflib_device_register fails
>   r73: Log iflib_tx_structures_setup failure in function
>

Is this an acceptable style for MFC logs?

I'm asking because I actually prefer this to reading (or compiling) the
concatenated log messages from several changes. However, I never knew it
was acceptable to summarize like this. If it is, I'd like to know so I can
adopt it for run-of-the-mill MFCs.

Jonathan
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r333503 - stable/11/sys/net

[Stephen Hurd]

Author: shurd
Date: Fri May 11 20:40:26 2018
New Revision: 333503
URL: https://svnweb.freebsd.org/changeset/base/333503

Log:
  MFC r29, r66, r73
  
  r29: Fix off-by-one error requesting tx interrupt
  r66: Cleanup queues when iflib_device_register fails
  r73: Log iflib_tx_structures_setup failure in function
  
  Approved by:  re (gjb@)
  Sponsored by: Limelight Networks
  Differential Revision:https://reviews.freebsd.org/D15354

Modified:
  stable/11/sys/net/iflib.c
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/net/iflib.c
==
--- stable/11/sys/net/iflib.c   Fri May 11 20:08:28 2018(r333502)
+++ stable/11/sys/net/iflib.c   Fri May 11 20:40:26 2018(r333503)
@@ -3269,7 +3269,7 @@ defrag:
 */
txq->ift_rs_pending += nsegs + 1;
if (txq->ift_rs_pending > TXQ_MAX_RS_DEFERRED(txq) ||
-iflib_no_tx_batch || (TXQ_AVAIL(txq) - nsegs - 1) <= 
MAX_TX_DESC(ctx)) {
+iflib_no_tx_batch || (TXQ_AVAIL(txq) - nsegs) <= MAX_TX_DESC(ctx) 
+ 2) {
pi.ipi_flags |= IPI_TX_INTR;
txq->ift_rs_pending = 0;
}
@@ -4342,10 +4342,8 @@ iflib_device_register(device_t dev, void *sc, if_share
goto fail;
}
 
-   if ((err = iflib_qset_structures_setup(ctx))) {
-   device_printf(dev, "qset structure setup failed %d\n", err);
+   if ((err = iflib_qset_structures_setup(ctx)))
goto fail_queues;
-   }
/*
 * Group taskqueues aren't properly set up until SMP is started,
 * so we disable interrupts until we can handle them post
@@ -4392,7 +4390,8 @@ fail_intr_free:
if (scctx->isc_intr == IFLIB_INTR_MSIX || scctx->isc_intr == 
IFLIB_INTR_MSI)
pci_release_msi(ctx->ifc_dev);
 fail_queues:
-   /* XXX free queues */
+   iflib_tx_structures_free(ctx);
+   iflib_rx_structures_free(ctx);
 fail:
IFDI_DETACH(ctx);
return (err);
@@ -5003,14 +5002,18 @@ iflib_qset_structures_setup(if_ctx_t ctx)
 {
int err;
 
-   if ((err = iflib_tx_structures_setup(ctx)) != 0)
+   /*
+* It is expected that the caller takes care of freeing queues if this
+* fails.
+*/
+   if ((err = iflib_tx_structures_setup(ctx)) != 0) {
+   device_printf(ctx->ifc_dev, "iflib_tx_structures_setup failed: 
%d\n", err);
return (err);
+   }
 
-   if ((err = iflib_rx_structures_setup(ctx)) != 0) {
+   if ((err = iflib_rx_structures_setup(ctx)) != 0)
device_printf(ctx->ifc_dev, "iflib_rx_structures_setup failed: 
%d\n", err);
-   iflib_tx_structures_free(ctx);
-   iflib_rx_structures_free(ctx);
-   }
+
return (err);
 }
 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"