Re: [PATCH] HTTP 103 response (Early Hints)

[Willy Tarreau]

On Tue, Nov 13, 2018 at 07:48:38AM +0100, Aleksandar Lazic wrote:
> Hi Fred.
> 
> Sorry to be picky but I still think that there is some missing text in the 
> documentation, as mentioned before.
> 
> http://git.haproxy.org/?p=haproxy.git;a=commitdiff;h=06f5b6435ba99b7a6a034d27b56192e16249f6f0
> 
> MINOR: doc: Add information about "early-hint" http-request action.

Ah indeed, looks like a "hit enter too fast" issue.

Thanks for spotting this!
Willy

Re: [PATCH] HTTP 103 response (Early Hints)

[Aleksandar Lazic]

Hi Fred.

Sorry to be picky but I still think that there is some missing text in the 
documentation, as mentioned before.

http://git.haproxy.org/?p=haproxy.git;a=commitdiff;h=06f5b6435ba99b7a6a034d27b56192e16249f6f0

MINOR: doc: Add information about "early-hint" http-request action.

As I could be wrong, just ignore this mail.

Regards
Aleks


 Ursprüngliche Nachricht 
Von: Willy Tarreau 
Gesendet: 12. November 2018 21:09:23 MEZ
An: Frederic Lecaille 
CC: HAProxy 
Betreff: Re: [PATCH] HTTP 103 response (Early Hints)

On Mon, Nov 12, 2018 at 03:38:28PM +0100, Frederic Lecaille wrote:
> Hello,
> 
> Here is a little series of patches to implement a new http-request
> action named "early-hint" to add HTTP 103 responses prior to any other
> response with headers whose values are defined by log-format rules, as
> this is done with "(add|del)-header" action.

Cool! Applied, thank you Fred :-)

Willy

Re: HTTP/3 | daniel.haxx.se

[Aleksandar Lazic]

Am 12.11.2018 um 23:31 schrieb Willy Tarreau:
> On Mon, Nov 12, 2018 at 10:52:41PM +0100, Aleksandar Lazic wrote:
>> Oh wow this is really a good time to get the hands dirty as QUIC is a major
>> design change in HTTP, IMHO.
> 
> Some first approaches were already attempted about one year ago already,
> to avoid being later in the party. But just like when we had to work on
> H2, trying to stuff this into an existing stream-based component is not
> easy and we ended up identifying a lot of lower layers that had to be
> changed first, so this work was paused and the protocol changed a lot
> during that time.
> 
>> To adopt the matrix from one of the last message, haproxy will be able to do 
>> the
>> conversion in almost every direction?
>>
>> HTTP/1.x <> HTTP/2
>> HTTP/2 <> HTTP/3
>> HTTP/1.x <> HTTP/3
>> HTTP/3 <> HTTP/3
> 
> Yes, that's the idea. In fact it will be slightly different, we're 
> implementing
> protocol conversion at the lower layers, to an internal version-agnostic HTTP
> representation supposed to accurately represent a message while keeping its
> semantics, that we've called HTX. I know that you love ASCII art, so it will
> look more or less like this (we'll have to provide a lot of doc but first we
> really want to focus on getting the code merged) :
> 
> 
>+---+ stream
>|   all HTTP processing | layer
>+---+
>^ ^ ^  ^
>HTX | HTX | HTX |  HTX |  normalised
>v v v  v  interface
>+--+ ++ ++ ++
>|applet| | HTTP/1 | | HTTP/2 | | HTTP/3 | whatever layer (called mux for 
> now
>+--+ ++ ++ ++ but may change once we have 
> others,
> cache || ||| could be presentation in OSI)
> stats | +--+  |+--+
> Lua svc   | |TLS   |  || QUIC |  transport layer
>   | +--+  |+--+ 
>   |   |   ||
> +-+ +-+
> | TCP/Unix/socketpair | | UDP |  control layer
> +-+ +-+
>   ||
>+--+
>|file descriptor   |  socket layer
>+--+
>|
>  +---+
>  | operating |
>  |  system   |
>  +---+
> 
> 
> It's really over-simplified since several layers above in fact have multiple
> upper arrows as they are multiplexed, but it's to explain more or less how
> stuff gets stacked. And since there are always transition periods, you have
> multiple protocols possible between each layer, otherwise it wouldn't be
> fun.  You have coded in the very old version where the file descriptors
> were directly present in the stream layer. As you can see, over a decade
> a lot of new layers have been built between the operating system and the
> streams, without even losing features nor compatibility. That's where the
> real challenges are.

Thank you for the picture, you know me too good 8-).

I follow the development a "little" bit, and it's amazing how you and your team
was able to rewrite a lot of haproxy and keep a high level of compatibility and
stability.

BTW: I loved to see that std* logger is now there ;-)

>> Is this technically possible as the UDP/QUIC may have not some information 
>> that
>> the TCP/HTTP need?
> 
> People tend to confuse QUIC and UDP too much. QUIC more or less uses
> UDP as a replacement for IP, which doesn't require privileges, and it
> reimplements its own transport stack on top of it, with congestion
> control, multiplexing, encryption etc. So it effectively represents a
> reliable transport layer for multiple streams based on datagrams below.
> UDP is seen as the revolutionary thing when you tell someone that HTTP
> will work over UDP but that's absolutely not true, it's almost comparable
> to saying that HTTP works over UDP when you're doing it over TLS over
> TCP over OpenVPN over UDP.

Hm, sound complicated.

I think to debug this beast isn't that "easy" as for now with `curl -v ...`,
even QUIC is planned for curl ;-)

>> As I try to imagine the new design in HAProxy will it look like this?
>>
>> TCP(TCP|UDP) HTTP/1.x,HTTP/2,HTTP/3
>>   \  /
>>  HTTP/TCP/UDP Engine - (TCP|UDP) HTTP/1.x,HTTP/2,HTTP/3
>>  (Here happen some magic)
>>   /  \
>> UDP(TCP|UDP) HTTP/1.x,HTTP/2,HTTP/3
>>
>>
>> Really 8-O ?
> 
> Precisely not, see above ;-)
> 
>> What happens with other protocols like plain TCP/UDP or grpc and so on?
> 
> Nothing, no particular change, 

Re: HTTP/3 | daniel.haxx.se

[Willy Tarreau]

On Mon, Nov 12, 2018 at 10:52:41PM +0100, Aleksandar Lazic wrote:
> Oh wow this is really a good time to get the hands dirty as QUIC is a major
> design change in HTTP, IMHO.

Some first approaches were already attempted about one year ago already,
to avoid being later in the party. But just like when we had to work on
H2, trying to stuff this into an existing stream-based component is not
easy and we ended up identifying a lot of lower layers that had to be
changed first, so this work was paused and the protocol changed a lot
during that time.

> To adopt the matrix from one of the last message, haproxy will be able to do 
> the
> conversion in almost every direction?
> 
> HTTP/1.x <> HTTP/2
> HTTP/2 <> HTTP/3
> HTTP/1.x <> HTTP/3
> HTTP/3 <> HTTP/3

Yes, that's the idea. In fact it will be slightly different, we're implementing
protocol conversion at the lower layers, to an internal version-agnostic HTTP
representation supposed to accurately represent a message while keeping its
semantics, that we've called HTX. I know that you love ASCII art, so it will
look more or less like this (we'll have to provide a lot of doc but first we
really want to focus on getting the code merged) :


   +---+ stream
   |   all HTTP processing | layer
   +---+
   ^ ^ ^  ^
   HTX | HTX | HTX |  HTX |  normalised
   v v v  v  interface
   +--+ ++ ++ ++
   |applet| | HTTP/1 | | HTTP/2 | | HTTP/3 | whatever layer (called mux for now
   +--+ ++ ++ ++ but may change once we have others,
cache || ||| could be presentation in OSI)
stats | +--+  |+--+
Lua svc   | |TLS   |  || QUIC |  transport layer
  | +--+  |+--+ 
  |   |   ||
+-+ +-+
| TCP/Unix/socketpair | | UDP |  control layer
+-+ +-+
  ||
   +--+
   |file descriptor   |  socket layer
   +--+
   |
 +---+
 | operating |
 |  system   |
 +---+


It's really over-simplified since several layers above in fact have multiple
upper arrows as they are multiplexed, but it's to explain more or less how
stuff gets stacked. And since there are always transition periods, you have
multiple protocols possible between each layer, otherwise it wouldn't be
fun.  You have coded in the very old version where the file descriptors
were directly present in the stream layer. As you can see, over a decade
a lot of new layers have been built between the operating system and the
streams, without even losing features nor compatibility. That's where the
real challenges are.

> Is this technically possible as the UDP/QUIC may have not some information 
> that
> the TCP/HTTP need?

People tend to confuse QUIC and UDP too much. QUIC more or less uses
UDP as a replacement for IP, which doesn't require privileges, and it
reimplements its own transport stack on top of it, with congestion
control, multiplexing, encryption etc. So it effectively represents a
reliable transport layer for multiple streams based on datagrams below.
UDP is seen as the revolutionary thing when you tell someone that HTTP
will work over UDP but that's absolutely not true, it's almost comparable
to saying that HTTP works over UDP when you're doing it over TLS over
TCP over OpenVPN over UDP.


> As I try to imagine the new design in HAProxy will it look like this?
> 
> TCP(TCP|UDP) HTTP/1.x,HTTP/2,HTTP/3
>   \  /
>  HTTP/TCP/UDP Engine - (TCP|UDP) HTTP/1.x,HTTP/2,HTTP/3
>  (Here happen some magic)
>   /  \
> UDP(TCP|UDP) HTTP/1.x,HTTP/2,HTTP/3
> 
> 
> Really 8-O ?

Precisely not, see above ;-)

> What happens with other protocols like plain TCP/UDP or grpc and so on?

Nothing, no particular change, that's the purpose of the stack you see
above. In fact from the info gathered, gRPC will only require that our
H2 mux supports trailers, which were not needed till they unearthed them.
But I want to see end-to-end H2 before working on trailers, as trailers
alone are useless, but H2 end-to-end is useful!

> Sorry a lot of questions, but you know I'm curious and try to understand some
> parts of the future ;-).

Yes I know, and you're welcome! It's important to discuss design but I
don't want to bore people with it, so it's easier if I have to answer
questions ;-)

> > We still have a lot of work to be done before supporting QUIC 

Re: HTTP/3 | daniel.haxx.se

[Aleksandar Lazic]

Hi Willy.

Am 12.11.2018 um 21:01 schrieb Willy Tarreau:
> On Mon, Nov 12, 2018 at 07:42:21PM +0100, Aleksandar Lazic wrote:
>> Even I agree with you to the point that HAProxy should be able to handle this
>> next upcomming/available technology, I'm not sure if it's really a benefit
>> for us, the enduser.
> 
> Hey, why do you guys imagine we're suffering that much redesigning all the
> connection management in 1.9 and making HTTP processing version-agnostic ?
> :-)

Well because you love to challenge your self, I'm just kidding ;-)

Oh wow this is really a good time to get the hands dirty as QUIC is a major
design change in HTTP, IMHO.

To adopt the matrix from one of the last message, haproxy will be able to do the
conversion in almost every direction?

HTTP/1.x <> HTTP/2
HTTP/2 <> HTTP/3
HTTP/1.x <> HTTP/3
HTTP/3 <> HTTP/3

Is this technically possible as the UDP/QUIC may have not some information that
the TCP/HTTP need?

As I try to imagine the new design in HAProxy will it look like this?

TCP(TCP|UDP) HTTP/1.x,HTTP/2,HTTP/3
  \  /
 HTTP/TCP/UDP Engine - (TCP|UDP) HTTP/1.x,HTTP/2,HTTP/3
 (Here happen some magic)
  /  \
UDP(TCP|UDP) HTTP/1.x,HTTP/2,HTTP/3


Really 8-O ?

What happens with other protocols like plain TCP/UDP or grpc and so on?

Sorry a lot of questions, but you know I'm curious and try to understand some
parts of the future ;-).

> We still have a lot of work to be done before supporting QUIC but we've
> started to have a clear idea how that will fit. The only thing is that
> experience taught us the the devil is in the details, and haproxy has
> accumulated a lot of details over the years.

Oh yes as always, this devil lay there for years and suddenly he jumps out and
say "nana I'm here" 8-O.

> Willy

Cheers
Aleks

Re: [PATCH] HTTP 103 response (Early Hints)

[Aleksandar Lazic]

Hi Willy.

Am 12.11.2018 um 21:14 schrieb Willy Tarreau:
> Hi Aleks,
> 
> On Mon, Nov 12, 2018 at 06:00:25PM +0100, Aleksandar Lazic wrote:
>> Hi Fred.
>>
>> Am 12.11.2018 um 15:38 schrieb Frederic Lecaille:
>>> Hello,
>>>
>>> Here is a little series of patches to implement a new http-request
>>> action named "early-hint" to add HTTP 103 responses prior to any other
>>> response with headers whose values are defined by log-format rules, as
>>> this is done with "(add|del)-header" action.
>>
>> Cool ;-) , what can I do with that feature?
> 
> You can send some Link header fields to the client immediately before the
> server even gets the request. This allows the client to start to preload
> some contents that you're sure will be needed, without having to wait for
> the server's response to discover this. In reality the purpose is to make
> efficient use of the server's think time which can often be larger than
> one RTT. For many purposes it can be more interesting than PUSH because
> it will even allow the client to fetch from another origin, via a CDN or
> whatever (think for example about the number of sites referencing jquery.js
> or whatever CSS from Cloudflare).
> 
> This technique is still very new and is documented in RFC 8297 produced
> by the IETF HTTP workgroup. Browser support is still unclear in that the
> "link: preload" stuff is also very new and possibly at different maturity
> stages in browsers. But browsers also need server-side components to be
> available in order to improve their support, and since it's easy for us,
> let's provide our share of the work in making the net faster ;-)
Full Ack.

Thank you very much for the detailed explanation ;-)
That sounds a really great solution.

> Cheers,
> Willy

Regards
Aleks

Re: [PATCH] HTTP 103 response (Early Hints)

[Willy Tarreau]

Hi Aleks,

On Mon, Nov 12, 2018 at 06:00:25PM +0100, Aleksandar Lazic wrote:
> Hi Fred.
> 
> Am 12.11.2018 um 15:38 schrieb Frederic Lecaille:
> > Hello,
> > 
> > Here is a little series of patches to implement a new http-request
> > action named "early-hint" to add HTTP 103 responses prior to any other
> > response with headers whose values are defined by log-format rules, as
> > this is done with "(add|del)-header" action.
> 
> Cool ;-) , what can I do with that feature?

You can send some Link header fields to the client immediately before the
server even gets the request. This allows the client to start to preload
some contents that you're sure will be needed, without having to wait for
the server's response to discover this. In reality the purpose is to make
efficient use of the server's think time which can often be larger than
one RTT. For many purposes it can be more interesting than PUSH because
it will even allow the client to fetch from another origin, via a CDN or
whatever (think for example about the number of sites referencing jquery.js
or whatever CSS from Cloudflare).

This technique is still very new and is documented in RFC 8297 produced
by the IETF HTTP workgroup. Browser support is still unclear in that the
"link: preload" stuff is also very new and possibly at different maturity
stages in browsers. But browsers also need server-side components to be
available in order to improve their support, and since it's easy for us,
let's provide our share of the work in making the net faster ;-)

Cheers,
Willy

Re: [PATCH] HTTP 103 response (Early Hints)

[Willy Tarreau]

On Mon, Nov 12, 2018 at 03:38:28PM +0100, Frederic Lecaille wrote:
> Hello,
> 
> Here is a little series of patches to implement a new http-request
> action named "early-hint" to add HTTP 103 responses prior to any other
> response with headers whose values are defined by log-format rules, as
> this is done with "(add|del)-header" action.

Cool! Applied, thank you Fred :-)

Willy

Re: HTTP/3 | daniel.haxx.se

[Willy Tarreau]

On Mon, Nov 12, 2018 at 07:42:21PM +0100, Aleksandar Lazic wrote:
> Even I agree with you to the point that HAProxy should be able to handle this
> next upcomming/available technology, I'm not sure if it's really a benefit
> for us, the enduser.

Hey, why do you guys imagine we're suffering that much redesigning all the
connection management in 1.9 and making HTTP processing version-agnostic ?
:-)

We still have a lot of work to be done before supporting QUIC but we've
started to have a clear idea how that will fit. The only thing is that
experience taught us the the devil is in the details, and haproxy has
accumulated a lot of details over the years.

Willy

Re: HTTP/3 | daniel.haxx.se

[Aleksandar Lazic]

Hi Manu.

Even I agree with you to the point that HAProxy should be able to handle this 
next upcomming/available technology, I'm not sure if it's really a benefit for 
us, the enduser.

The future will show it :-)

As I don't want to bother all members on the list with this topic, let's 
discuss it  further off the list, if you like.

Regads aleks


 Ursprüngliche Nachricht 
Von: Emmanuel Hocdet 
Gesendet: 12. November 2018 18:44:40 MEZ
An: Aleksandar Lazic 
CC: haproxy@formilux.org
Betreff: Re: HTTP/3 | daniel.haxx.se


Hi Aleks,

> Le 12 nov. 2018 à 18:02, Aleksandar Lazic  a écrit :
> 
> Hi Manu.
> 
> Am 12.11.2018 um 16:19 schrieb Emmanuel Hocdet:
>> 
>> Hi,
>> 
>> The primary (major) step should be to deal with QUIC transport (over UDP).
>> At the same level as TCP for haproxy?
>> Willy should already have a little idea on it ;-)
> 
> Is then the conclusion for that that haproxy will be able to proxy/load 
> balance UDP?

The only conclusion is that haproxy should be able to proxy QUIC.
From wiki: «  QUIC, Quick UDP Internet Connections, aims to be nearly 
equivalent to an independent TCP 
 connection »
It could be see as TCP/2, the connection part is provided by the application. 
For example,  the congestion avoidance algorithms
must be provide into the application space at both endpoints.
A very cool feature is that QUIC can support IP migration.

++
Manu

Re: [PATCH]: BUILD/MEDIUM: DragonFly fix

[Willy TARREAU]

On Mon, Nov 12, 2018 at 04:25:19PM +, David CARLIER wrote:
> Sorry, bas patch... Here the correct one. Regards.

Merged, thank you David.

Willy

Re: HTTP/3 | daniel.haxx.se

[Emmanuel Hocdet]

Hi Aleks,

> Le 12 nov. 2018 à 18:02, Aleksandar Lazic  a écrit :
> 
> Hi Manu.
> 
> Am 12.11.2018 um 16:19 schrieb Emmanuel Hocdet:
>> 
>> Hi,
>> 
>> The primary (major) step should be to deal with QUIC transport (over UDP).
>> At the same level as TCP for haproxy?
>> Willy should already have a little idea on it ;-)
> 
> Is then the conclusion for that that haproxy will be able to proxy/load 
> balance UDP?

The only conclusion is that haproxy should be able to proxy QUIC.
From wiki: «  QUIC, Quick UDP Internet Connections, aims to be nearly 
equivalent to an independent TCP 
 connection »
It could be see as TCP/2, the connection part is provided by the application. 
For example,  the congestion avoidance algorithms
must be provide into the application space at both endpoints.
A very cool feature is that QUIC can support IP migration.

++
Manu

Re: HTTP/3 | daniel.haxx.se

[Aleksandar Lazic]

Hi Manu.

Am 12.11.2018 um 16:19 schrieb Emmanuel Hocdet:
> 
> Hi,
> 
> The primary (major) step should be to deal with QUIC transport (over UDP).
> At the same level as TCP for haproxy?
> Willy should already have a little idea on it ;-)

Is then the conclusion for that that haproxy will be able to proxy/load balance 
UDP?

> ++
> Manu
> 
>> Le 11 nov. 2018 à 20:38, Aleksandar Lazic  a écrit :
>>
>> Hi.
>>
>> FYI.
>>
>> Oh no, that was quite fast after HTTP/2
>>
>> https://daniel.haxx.se/blog/2018/11/11/http-3/
>>
>> Regards
>> Aleks
>>
> 
> 

Re: [PATCH] HTTP 103 response (Early Hints)

[Aleksandar Lazic]

Hi Fred.

Am 12.11.2018 um 15:38 schrieb Frederic Lecaille:
> Hello,
> 
> Here is a little series of patches to implement a new http-request
> action named "early-hint" to add HTTP 103 responses prior to any other
> response with headers whose values are defined by log-format rules, as
> this is done with "(add|del)-header" action.

Cool ;-) , what can I do with that feature?

Maybe there is some text missing in the configuration.txt patch?

0004-MINOR-doc-Add-information-about-early-hint-http-requ.patch

> Regards,
> 
> Fred.

Regards
Aleks

Re: [PATCH]: BUILD/MEDIUM: DragonFly fix

[David CARLIER]

The correct patch is in the second message, in case it was missed :-)

Thanks.

Regards.
On Mon, 12 Nov 2018 at 16:28, David CARLIER  wrote:
>
> No sorry that was a bad patch, I thought earlier DragonFlyBSD did not
> support but in fact it does.
> On Mon, 12 Nov 2018 at 16:25, Willy TARREAU  wrote:
> >
> > Hi David,
> >
> > On Mon, Nov 12, 2018 at 04:16:17PM +, David CARLIER wrote:
> > > Subject: [PATCH] BUILD/MEDIUM: DragonFlyBSD build fix
> > >
> > > This platform does not have particular build on its own, so it
> > > just uses historically the FreeBSD's. Only it does not support
> > > the thread/cpu binding.
> >
> > Is it only for threads that it doesn't support it or is it also
> > for processes ? I'm just asking because if it's general, we'd
> > better do it this way so that it remains consistent across all
> > the code :
> >
> > diff --git a/include/common/compat.h b/include/common/compat.h
> > index 8a7bbd5bf..8049a6095 100644
> > --- a/include/common/compat.h
> > +++ b/include/common/compat.h
> > @@ -162,6 +162,11 @@
> >  #define HA_HAVE_CRYPT_R
> >  #endif
> >
> > +/* DragonFly doesn't have CPU affinity */
> > +#ifndef __DragonFly__
> > +#undef USE_CPU_AFFINITY
> > +#endif
> > +
> >  #endif /* _COMMON_COMPAT_H */
> >
> >  /*
> >
> > But if it's only for threads, we can indeed proceed just at this place,
> > but then we have no option for emitting a warning (maybe that's not
> > dramatic). However then please fold the two ifdefs into one :
> >
> > >  #ifdef USE_CPU_AFFINITY
> > > +#ifndef __DragonFly__
> >
> > => #if defined(USE_CPU_AFFINITY) && !defined(__DragonFly__)
> >
> > Thanks,
> > Willy

Re: [PATCH]: BUILD/MEDIUM: DragonFly fix

[David CARLIER]

No sorry that was a bad patch, I thought earlier DragonFlyBSD did not
support but in fact it does.
On Mon, 12 Nov 2018 at 16:25, Willy TARREAU  wrote:
>
> Hi David,
>
> On Mon, Nov 12, 2018 at 04:16:17PM +, David CARLIER wrote:
> > Subject: [PATCH] BUILD/MEDIUM: DragonFlyBSD build fix
> >
> > This platform does not have particular build on its own, so it
> > just uses historically the FreeBSD's. Only it does not support
> > the thread/cpu binding.
>
> Is it only for threads that it doesn't support it or is it also
> for processes ? I'm just asking because if it's general, we'd
> better do it this way so that it remains consistent across all
> the code :
>
> diff --git a/include/common/compat.h b/include/common/compat.h
> index 8a7bbd5bf..8049a6095 100644
> --- a/include/common/compat.h
> +++ b/include/common/compat.h
> @@ -162,6 +162,11 @@
>  #define HA_HAVE_CRYPT_R
>  #endif
>
> +/* DragonFly doesn't have CPU affinity */
> +#ifndef __DragonFly__
> +#undef USE_CPU_AFFINITY
> +#endif
> +
>  #endif /* _COMMON_COMPAT_H */
>
>  /*
>
> But if it's only for threads, we can indeed proceed just at this place,
> but then we have no option for emitting a warning (maybe that's not
> dramatic). However then please fold the two ifdefs into one :
>
> >  #ifdef USE_CPU_AFFINITY
> > +#ifndef __DragonFly__
>
> => #if defined(USE_CPU_AFFINITY) && !defined(__DragonFly__)
>
> Thanks,
> Willy

Re: [PATCH]: BUILD/MEDIUM: DragonFly fix

[Willy TARREAU]

Hi David,

On Mon, Nov 12, 2018 at 04:16:17PM +, David CARLIER wrote:
> Subject: [PATCH] BUILD/MEDIUM: DragonFlyBSD build fix
> 
> This platform does not have particular build on its own, so it
> just uses historically the FreeBSD's. Only it does not support
> the thread/cpu binding.

Is it only for threads that it doesn't support it or is it also
for processes ? I'm just asking because if it's general, we'd
better do it this way so that it remains consistent across all
the code :

diff --git a/include/common/compat.h b/include/common/compat.h
index 8a7bbd5bf..8049a6095 100644
--- a/include/common/compat.h
+++ b/include/common/compat.h
@@ -162,6 +162,11 @@
 #define HA_HAVE_CRYPT_R
 #endif
 
+/* DragonFly doesn't have CPU affinity */
+#ifndef __DragonFly__
+#undef USE_CPU_AFFINITY
+#endif
+
 #endif /* _COMMON_COMPAT_H */
 
 /*

But if it's only for threads, we can indeed proceed just at this place,
but then we have no option for emitting a warning (maybe that's not
dramatic). However then please fold the two ifdefs into one :

>  #ifdef USE_CPU_AFFINITY
> +#ifndef __DragonFly__

=> #if defined(USE_CPU_AFFINITY) && !defined(__DragonFly__)

Thanks,
Willy

Re: [PATCH]: BUILD/MEDIUM: DragonFly fix

[David CARLIER]

Sorry, bas patch... Here the correct one. Regards.
On Mon, 12 Nov 2018 at 16:16, David CARLIER  wrote:
>
> Hi,
>
> Here a little patch proposal to fix this plarticular platform build.
>
> Cheers.
From e16a4199362748b2492c89e9693e845df28a2eb4 Mon Sep 17 00:00:00 2001
From: David Carlier 
Date: Mon, 12 Nov 2018 16:22:19 +
Subject: [PATCH] BUILD/MEDIUM: DragonFly build fix

DragonFlyBSD does not have a build on its own, it has always
used the FreeBSD's. To be able to support the cpu affinity,
it needs few more headers.
---
 src/haproxy.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/haproxy.c b/src/haproxy.c
index 1d2971d4..c7148222 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -52,9 +52,11 @@
 #include 
 #ifdef USE_CPU_AFFINITY
 #include 
-#ifdef __FreeBSD__
+#if defined(__FreeBSD__) || defined(__DragonFly__)
 #include 
+#ifdef __FreeBSD__
 #include 
+#endif
 #include 
 #endif
 #endif
-- 
2.18.0

[PATCH]: BUILD/MEDIUM: DragonFly fix

[David CARLIER]

Hi,

Here a little patch proposal to fix this plarticular platform build.

Cheers.
From 3155cfe8230a1adc6f4878c038474ec9d2aadbc3 Mon Sep 17 00:00:00 2001
From: David Carlier 
Date: Mon, 12 Nov 2018 16:11:14 +
Subject: [PATCH] BUILD/MEDIUM: DragonFlyBSD build fix

This platform does not have particular build on its own, so it
just uses historically the FreeBSD's. Only it does not support
the thread/cpu binding.
---
 src/haproxy.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/haproxy.c b/src/haproxy.c
index 1d2971d4..9e701215 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -3246,6 +3246,7 @@ int main(int argc, char **argv)
 			pthread_create([i], NULL, _thread_poll_loop, [i]);
 
 #ifdef USE_CPU_AFFINITY
+#ifndef __DragonFly__
 		/* Now the CPU affinity for all threads */
 		for (i = 0; i < global.nbthread; i++) {
 			if (global.cpu_map.proc[relative_pid-1])
@@ -3271,6 +3272,7 @@ int main(int argc, char **argv)
 		   sizeof(cpuset), );
 			}
 		}
+#endif
 #endif /* !USE_CPU_AFFINITY */
 
 		/* when multithreading we need to let only the thread 0 handle the signals */
-- 
2.18.0

Re: HTTP/3 | daniel.haxx.se

[Emmanuel Hocdet]

Hi,

The primary (major) step should be to deal with QUIC transport (over UDP).
At the same level as TCP for haproxy?
Willy should already have a little idea on it ;-)

++
Manu

> Le 11 nov. 2018 à 20:38, Aleksandar Lazic  a écrit :
> 
> Hi.
> 
> FYI.
> 
> Oh no, that was quite fast after HTTP/2
> 
> https://daniel.haxx.se/blog/2018/11/11/http-3/
> 
> Regards
> Aleks
>