Page MenuHomeFreeBSD

jch (Julien Charbon)
User

Projects

User Details

User Since
Sep 24 2014, 4:00 PM (229 w, 2 d)

Recent Activity

Nov 12 2018

jch committed rS340375: cxgbe/netmap: Fix cxgbe netmap when interface is DOWN.
cxgbe/netmap: Fix cxgbe netmap when interface is DOWN
Nov 12 2018, 5:57 PM
jch closed D17802: Fix cxgbe netmap when interface is DOWN.
Nov 12 2018, 5:57 PM

Nov 11 2018

jch added a reviewer for D17910: netmap: automatically disable some capabilities over vlan interface: v.maffione_gmail.com.
Nov 11 2018, 10:12 PM
jch added a reviewer for D17896: netmap: netmap_transmit should honor bpf packet tap hook.: v.maffione_gmail.com.
Nov 11 2018, 10:10 PM
jch added a parent revision for D17951: Chelsio/netmap: propagate disabled IFCAP checksum flags to kernel: D17910: netmap: automatically disable some capabilities over vlan interface.
Nov 11 2018, 9:54 PM
jch added a child revision for D17910: netmap: automatically disable some capabilities over vlan interface: D17951: Chelsio/netmap: propagate disabled IFCAP checksum flags to kernel.
Nov 11 2018, 9:54 PM
jch added a reviewer for D17951: Chelsio/netmap: propagate disabled IFCAP checksum flags to kernel: np.
Nov 11 2018, 9:51 PM
jch created D17951: Chelsio/netmap: propagate disabled IFCAP checksum flags to kernel.
Nov 11 2018, 9:51 PM

Nov 9 2018

jch updated the summary of D17889: RFC: TCP: Add close timeout support.
Nov 9 2018, 7:31 AM

Nov 7 2018

jch created D17889: RFC: TCP: Add close timeout support.
Nov 7 2018, 1:05 PM
jch created D17886: RFC: Chelsio/netmap: Allow netmap to be used on main interface.
Nov 7 2018, 10:27 AM

Nov 5 2018

jch updated the diff for D17802: Fix cxgbe netmap when interface is DOWN.

Address @np comment

Nov 5 2018, 9:34 PM
jch added a comment to D17802: Fix cxgbe netmap when interface is DOWN.
In D17802#381512, @np wrote:

Can you provide exact steps to reproduce the problem that you described? I get an EAGAIN (as expected) and not a panic if I try to enable netmap when the link is down.

Nov 5 2018, 9:29 PM
jch updated the diff for D17802: Fix cxgbe netmap when interface is DOWN.

Address @np comment

Nov 5 2018, 9:26 PM
jch added a comment to D17843: Fix Chelsio T6 drop statistics.
In D17843#381446, @np wrote:

What version of FreeBSD is this? I think this is already fixed in 12.0.

Nov 5 2018, 5:57 PM
jch created D17843: Fix Chelsio T6 drop statistics.
Nov 5 2018, 12:21 PM

Nov 1 2018

jch created D17802: Fix cxgbe netmap when interface is DOWN.
Nov 1 2018, 3:25 PM

Jun 15 2018

jch added a comment to D15686: convert inpcbhash rlock to epoch.

@jch sounds simple enough to replicate, nonetheless can you share any benchmark source?

Jun 15 2018, 6:43 AM

Jun 13 2018

jch added a comment to D15686: convert inpcbhash rlock to epoch.

[snip]
I think you slightly misread my comment. It was not so much that I am concerned that there is a pathological case in theory (clearly those exist all over the place), it's that in practical use this could shift the watermark on allocated inpcbs substantially in some real-world workloads, and that it would be good to seek some testing from who work with such workloads, which differ substantially from the target workload for this work (as I understand it). In the past, work on who connections/sec support has been primarily driven by the folk at Verisign doing top-level domain hosting, and who have a good test setup for that. I wonder if they'd be willing to give this a spin and in particular look for evidence of impact on connections/sec to make sure that this doesn't lead to a substantive decrease (and ideally instead leads to an increase) in connection throughput.

It seems unlikely that a 2ms backlog of inpcbs could alter the connection rate, vs new connections not blocking on callouts and all the various points that acquire an info read lock. Verisign has not been responsive of late, but if they're willing to test that would be an interesting data point.

Jun 13 2018, 7:47 AM

Oct 24 2017

jch committed rS324948: MFC r324179, r324193:.
MFC r324179, r324193:
Oct 24 2017, 8:56 AM

Oct 2 2017

jch committed rS324193: Forgotten bits in r324179: Include sys/syslog.h if INVARIANTS is not defined.
Forgotten bits in r324179: Include sys/syslog.h if INVARIANTS is not defined
Oct 2 2017, 9:45 AM

Oct 1 2017

jch committed rS324179: Fix an infinite loop in tcp_tw_2msl_scan() when an INP_TIMEWAIT inp has.
Fix an infinite loop in tcp_tw_2msl_scan() when an INP_TIMEWAIT inp has
Oct 1 2017, 9:20 PM
jch closed D12267: Fix an infinite loop in tcp_tw_2msl_scan() when an INP_TIMEWAIT inp has been destroyed before its tcptw with INVARIANTS undefined..
Oct 1 2017, 9:20 PM

Sep 7 2017

jch created D12267: Fix an infinite loop in tcp_tw_2msl_scan() when an INP_TIMEWAIT inp has been destroyed before its tcptw with INVARIANTS undefined..
Sep 7 2017, 3:12 PM

Jan 17 2017

jch committed rD49867: Update my PGP key before expiration.
Update my PGP key before expiration
Jan 17 2017, 2:45 PM

Nov 24 2016

jch committed rS309108: MFC r286227, r286443:.
MFC r286227, r286443:
Nov 24 2016, 2:49 PM

Nov 7 2016

jch committed rS308426: MFC r307966:.
MFC r307966:
Nov 7 2016, 6:29 PM

Nov 3 2016

jch committed rS308263: MFC r307966:.
MFC r307966:
Nov 3 2016, 7:58 PM

Oct 26 2016

jch closed D8072: Remove an extraneous call to soisconnected() in syncache_socket(), introduced with r261242. by committing rS307966: Remove an extraneous call to soisconnected() in syncache_socket(),.
Oct 26 2016, 3:19 PM
jch committed rS307966: Remove an extraneous call to soisconnected() in syncache_socket(),.
Remove an extraneous call to soisconnected() in syncache_socket(),
Oct 26 2016, 3:19 PM

Oct 25 2016

jch added a comment to D8211: Fix a double-free when an inp transitions to INP_TIMEWAIT state after having been dropped..

Fixed and MFC'ed with rS307551: Fix a double-free when an inp transitions to INP_TIMEWAIT state.

Oct 25 2016, 1:00 PM
jch committed rS307906: MFC r307551:.
MFC r307551:
Oct 25 2016, 12:58 PM
jch closed D8211: Fix a double-free when an inp transitions to INP_TIMEWAIT state after having been dropped..
Oct 25 2016, 12:56 PM
jch committed rS307905: MFC r307551:.
MFC r307551:
Oct 25 2016, 12:53 PM

Oct 19 2016

jch added a comment to D8211: Fix a double-free when an inp transitions to INP_TIMEWAIT state after having been dropped..

gnn accepted this revision.

Oct 19 2016, 1:17 PM

Oct 18 2016

jch committed rS307551: Fix a double-free when an inp transitions to INP_TIMEWAIT state.
Fix a double-free when an inp transitions to INP_TIMEWAIT state
Oct 18 2016, 7:16 AM

Oct 17 2016

jch added a comment to D8211: Fix a double-free when an inp transitions to INP_TIMEWAIT state after having been dropped..

Still need someone from -transport to approve this review though. :)

Oct 17 2016, 1:59 PM
jch added a reviewer for D8211: Fix a double-free when an inp transitions to INP_TIMEWAIT state after having been dropped.: gnn.
Oct 17 2016, 1:58 PM
jch added a comment to D8211: Fix a double-free when an inp transitions to INP_TIMEWAIT state after having been dropped..

I was testing this patch in 3 days.
No TCP related problems.

Oct 17 2016, 11:03 AM

Oct 13 2016

jch updated the diff for D8211: Fix a double-free when an inp transitions to INP_TIMEWAIT state after having been dropped..

Review from Slawa:

  • log(LOG_ERR) and workaround a difficult to debug case when INVARIANT is not defined
  • Add a tcp_twstart KASSERT
Oct 13 2016, 9:21 AM

Oct 12 2016

jch added a comment to D8072: Remove an extraneous call to soisconnected() in syncache_socket(), introduced with r261242..

Thanks for your time on this review, will push this change as soon as D8211: Fix a double-free when an inp transitions to INP_TIMEWAIT state after having been dropped. is complete.

Oct 12 2016, 6:52 AM

Oct 10 2016

jch added a comment to D8211: Fix a double-free when an inp transitions to INP_TIMEWAIT state after having been dropped..

I think imp also have reproduced this issue (https://lists.freebsd.org/pipermail/freebsd-stable/2016-September/085518.html)
Also report Urmas Lett <urmas.lett@eenet.ee> (email to jch)

Oct 10 2016, 11:42 AM
jch updated the diff for D8211: Fix a double-free when an inp transitions to INP_TIMEWAIT state after having been dropped..

Fix a comment typo

Oct 10 2016, 11:41 AM
jch updated D8211: Fix a double-free when an inp transitions to INP_TIMEWAIT state after having been dropped..
Oct 10 2016, 11:36 AM
jch added a comment to D8211: Fix a double-free when an inp transitions to INP_TIMEWAIT state after having been dropped..

Currently only @slw_zxy.spb.ru and @girgen have reproduced this issue thus are able to validate this change, I have not been able to reproduce it but our TCP QA is all good with this change.

Oct 10 2016, 11:12 AM
jch added reviewers for D8211: Fix a double-free when an inp transitions to INP_TIMEWAIT state after having been dropped.: slw_zxy.spb.ru, girgen.
Oct 10 2016, 11:10 AM
jch retitled D8211: Fix a double-free when an inp transitions to INP_TIMEWAIT state after having been dropped. from to Fix a double-free when an inp transitions to INP_TIMEWAIT state after having been dropped..
Oct 10 2016, 11:09 AM

Oct 9 2016

jch committed rS306925: MFC r306443:.
MFC r306443:
Oct 9 2016, 9:35 PM
jch committed rS306922: MFC r306443:.
MFC r306443:
Oct 9 2016, 9:02 PM

Sep 30 2016

jch updated D8072: Remove an extraneous call to soisconnected() in syncache_socket(), introduced with r261242..
Sep 30 2016, 6:52 AM

Sep 29 2016

jch retitled D8072: Remove an extraneous call to soisconnected() in syncache_socket(), introduced with r261242. from to Remove an extraneous call to soisconnected() in syncache_socket(), introduced with r261242..
Sep 29 2016, 11:43 AM
jch committed rS306443: Fix an issue with accept_filter introduced with r261242:.
Fix an issue with accept_filter introduced with r261242:
Sep 29 2016, 11:19 AM

Jul 27 2016

jch committed rS303389: MFC r286873:.
MFC r286873:
Jul 27 2016, 1:53 PM
jch committed rS303371: MFC r271119, r272081:.
MFC r271119, r272081:
Jul 27 2016, 7:52 AM
jch committed rS303365: MFC r273014:.
MFC r273014:
Jul 27 2016, 6:32 AM

Jul 18 2016

jch committed rS302995: MFC r261242:.
MFC r261242:
Jul 18 2016, 8:20 AM

Jul 14 2016

jch added a reviewer for D7135: A problem with ASYNC drain: jch.
Jul 14 2016, 4:58 PM

Jul 6 2016

jch added a reviewer for D7136: TCP Timer cleanup: jch.
Jul 6 2016, 11:26 AM

Jul 4 2016

jch added a comment to D7042: When a callout is being run and scheduled at the same time, callout_stop() would only unschedule the scheduled one, but will not drain the running one..

I would not agree that there is API change for callout_stop(). Let's look into the manual page:
...

The problem is that the whole paradigm of callouts is that it has three consequent states: not scheduled -> scheduled -> running -> not scheduled. The API and the manual page assume that, some comments in the code assume that, and looks like some contributors to the code also did. But this paradigm isn't true. A callout can be scheduled and running at the same time. And the mishandling of this state was the source of our TCP panics. Now let's get back to the documentation and see what should callout_stop() return if callout is scheduled and running at the same time. It should return 0 because callout is currently being serviced and can't be stopped. At the same time it should return 1, since it has successfully unscheduled a callout. So it must be 0 and 1 at the same time! :) Yep, which is impossible. The API is limited by wrong paradigm and we must select the most safe value between these two. Now, I assert that returning 1 is much less safe in this case. Because any properly designed user of the API will be ready to free resources that are now in use by running callout. This is exactly what happened with TCP. Any other user, use it async version or not, is also prone to panic if we return 1. I assert that returning 0 will make behaviour more safe, and won't break any users, since this is what a sane programmer would expect from API. To finalize, I would notice that this state of running+scheduled in practice is extremely rare, if we noticed it only now at above 50 Gbit/s. So, I'm strongly against limiting the behavior only to async version.

Jul 4 2016, 12:17 PM
jch added a comment to D7042: When a callout is being run and scheduled at the same time, callout_stop() would only unschedule the scheduled one, but will not drain the running one..

Looks good to me, let me launch our TCP QA on it.

Jul 4 2016, 12:14 PM

Jul 1 2016

jch added a comment to D7042: When a callout is being run and scheduled at the same time, callout_stop() would only unschedule the scheduled one, but will not drain the running one..

callout_stop() should return 0 when the callout is currently being serviced and indeed unstoppable.

I think this approach will add extra complications to the code.

I suggest to use:

static void
dummy_drain(void *arg)
{
}

ret = callout_async_drain(co, &dummy_drain, NULL);

Which is basically what you want and allow callout_async_drain() to update the callback function if called multiple times.

Instead of:

ret = callout_stop()

In this case. It returns the correct value for the client.

If callout_stop() always return 0 in the MPSAFE cc_exec_curr == c, it breaks the callout API possibly with out-of-the-tree code which we don't control.

Jul 1 2016, 9:23 AM
jch added a comment to D7042: When a callout is being run and scheduled at the same time, callout_stop() would only unschedule the scheduled one, but will not drain the running one..

I agree with this change spirit:

Jul 1 2016, 8:40 AM
jch added inline comments to D7042: When a callout is being run and scheduled at the same time, callout_stop() would only unschedule the scheduled one, but will not drain the running one..
Jul 1 2016, 8:23 AM

Apr 25 2016

jch accepted D5924: TCP Timer cleanup..

Tested on top of -CURRENT r298539 and all good. Performance are the same with and without this patch (this is expected). Green light from me.

Apr 25 2016, 5:40 AM

Apr 19 2016

jch added a comment to D5924: TCP Timer cleanup..

I starting testing this callout_async_drain() usage and so far so good. Let me upgrade our lab to a more recent revision of -CURRENT and I will report my findings here (should be by the end of this week).

Apr 19 2016, 11:22 AM

Apr 15 2016

jch added a comment to D5924: TCP Timer cleanup..
In D5924#126467, @rrs wrote:

jch: Thanks for running your torture tests.. I did not take out the flags you added though I
am not sure we need them anymore.. what do you think?

Apr 15 2016, 12:17 PM

Apr 12 2016

jch added a comment to D5924: TCP Timer cleanup..

Nice to see callout_async_drain() in action, TCP timer code being (much) cleaner. Will review this change, and run our usual TCP torture tests on it.

Apr 12 2016, 1:31 PM
jch added a reviewer for D5924: TCP Timer cleanup.: jch.
Apr 12 2016, 1:28 PM

Dec 23 2015

jch accepted D4350: TCP Fast Open (TFO) [RFC7413] Server-side Implementation.
Dec 23 2015, 8:33 AM
jch added a comment to D4350: TCP Fast Open (TFO) [RFC7413] Server-side Implementation.

I approve this server-side TFO implementation, it is a solid first implementation we can build on.

Dec 23 2015, 8:33 AM

Nov 3 2015

jch added inline comments to D3521: Implement callout_drain_async().
Nov 3 2015, 12:52 PM

Oct 16 2015

jch added a member for transport: jch.
Oct 16 2015, 7:41 AM
jch added a member for network: jch.
Oct 16 2015, 7:36 AM

Oct 9 2015

jch accepted D3856: Use callout drain async in the TCP stack.

Good example of using callout_drain_async().

Oct 9 2015, 1:25 PM
jch accepted D3521: Implement callout_drain_async().

I approve this change for MPSAFE callouts. As I lack of specific tests (and knowledge) for non-MPSAFE callouts, I would like another reviewer to look at it (@rrs?).

Oct 9 2015, 1:22 PM
jch added a comment to D3521: Implement callout_drain_async().

I have used and tested callout_async_drain() for TCP timer callouts and all good, everything works as expected. I would suggest you to create a review that depends on this one, to show how to use callout_async_drain() as a real example. What I did for my testing:

Oct 9 2015, 12:59 PM
jch added inline comments to D3521: Implement callout_drain_async().
Oct 9 2015, 10:01 AM
jch added inline comments to D3521: Implement callout_drain_async().
Oct 9 2015, 9:09 AM

Oct 8 2015

jch added a comment to D3521: Implement callout_drain_async().

I am indeed for adding callout_drain_async() as this is exactly what we are doing with TCP timer callouts in HEAD, stable/10 and releng/10.2, but it is currently done using callout_stop()/callout_reset() in a non simple way instead of using directly callout_drain_async().

Oct 8 2015, 4:47 PM
jch added inline comments to D3521: Implement callout_drain_async().
Oct 8 2015, 4:42 PM

Sep 15 2015

jch added inline comments to D3521: Implement callout_drain_async().
Sep 15 2015, 6:49 PM
jch added a comment to D3521: Implement callout_drain_async().

Let me try to try callout_drain_async() in top of our last TCP changes. I will put the results here.

Sep 15 2015, 3:28 PM
jch added inline comments to D3521: Implement callout_drain_async().
Sep 15 2015, 3:25 PM
jch added a comment to D3521: Implement callout_drain_async().

I do approve the addition of this function, it would have made my life much easier for these two tasks:

Sep 15 2015, 3:10 PM

Aug 30 2015

jch added a comment to D2763: Fix a callout race condition introduced in TCP timers callouts with r281599..

Change put back with rS287304: Put r284245 back in place: If at first this fix was seen as a temporary, as it turns out this change is not a workaround for a callout_stop() bug, but the right to use callout_stop()/callout_reset() in mpsafe mode. Should be the last change in the task to remove TCP timers race conditions started with D2079: Fix TCP timers use-after-free old race conditions.

Aug 30 2015, 7:59 PM
jch added a comment to D3078: callout_stop() should return 0 when the callout is currently being serviced and indeed unstoppable..

Change reverted in rS287305: Revert r286880: If at first this change made sense, it turns out, thanks for your time sharing the subtlety of callout_stop() in mpsafe mode.

Aug 30 2015, 2:02 PM
jch committed rS287305: Revert r286880: If at first this change made sense, it turns out.
Revert r286880: If at first this change made sense, it turns out
Aug 30 2015, 1:44 PM
jch committed rS287304: Put r284245 back in place: If at first this fix was seen as a temporary.
Put r284245 back in place: If at first this fix was seen as a temporary
Aug 30 2015, 1:44 PM
jch closed D3078: callout_stop() should return 0 when the callout is currently being serviced and indeed unstoppable. by committing rS287305: Revert r286880: If at first this change made sense, it turns out.
Aug 30 2015, 1:44 PM

Aug 27 2015

jch updated subscribers of D3078: callout_stop() should return 0 when the callout is currently being serviced and indeed unstoppable..

Hi guys, after emails exchanges with @helasky and @kib I believe that if this change makes sense and improves some callout usages (i.e. in TCP timers) it is not worth it overall. In details:

Aug 27 2015, 9:12 PM
jch updated subscribers of D3078: callout_stop() should return 0 when the callout is currently being serviced and indeed unstoppable..
Aug 27 2015, 12:31 PM
jch updated the diff for D3078: callout_stop() should return 0 when the callout is currently being serviced and indeed unstoppable..

Updated with hselaski inputs

Aug 27 2015, 12:29 PM
jch reopened D3078: callout_stop() should return 0 when the callout is currently being serviced and indeed unstoppable..
Aug 27 2015, 12:28 PM
jch committed rS287200: Silent a compilation warning on callout_stop().
Silent a compilation warning on callout_stop()
Aug 27 2015, 10:43 AM
jch committed rS287198: In callout_stop(), do not forget to initialize not_running variable..
In callout_stop(), do not forget to initialize not_running variable.
Aug 27 2015, 8:58 AM
jch committed rS287196: In callout_stop(), if a callout is both pending and currently.
In callout_stop(), if a callout is both pending and currently
Aug 27 2015, 8:15 AM

Aug 24 2015

jch accepted D2970: Undo the increase in sequence number by 1 due to the FIN flag in case of a transient error..

This change looks good to me.

Aug 24 2015, 9:49 AM
jch added a comment to D2599: Decompose TCP INP_INFO lock to increase short-lived connections scalability.

Just for the history below few commits that are related to this change:

Aug 24 2015, 9:40 AM
jch added a comment to D2763: Fix a callout race condition introduced in TCP timers callouts with r281599..

This change has been reverted with rS287101, as it is not need anymore with rS286880/D3078.

Aug 24 2015, 9:34 AM
jch committed rS287101: Revert r284245: "Fix a callout race condition introduced in TCP.
Revert r284245: "Fix a callout race condition introduced in TCP
Aug 24 2015, 9:30 AM