Re: ix(4): Add support for TCP Large Receive Offloading

2022-06-08 Thread Hrvoje Popovski
On 8.6.2022. 22:01, Hrvoje Popovski wrote: > On 8.6.2022. 15:04, Jan Klemkow wrote: >> Could you show me, how your setup and your configuration looks like? > Yes, of course .. > > All my lab boxes are connected to switch (no flow-control). In this > setup ix0 and ix1 are in aggr and vlans 700 and

Re: bgpd: refactor kroute code a fair bit

2022-06-08 Thread Claudio Jeker
On Wed, Jun 08, 2022 at 06:27:36PM +0200, Claudio Jeker wrote: > On Wed, Jun 08, 2022 at 06:10:21PM +0200, Theo Buehler wrote: > > On Wed, Jun 08, 2022 at 01:28:14PM +0200, Claudio Jeker wrote: > > > The idea behind this diff is to use struct kroute_full in more places. > > > Mainly when parsing ro

Re: ix(4): Add support for TCP Large Receive Offloading

2022-06-08 Thread Hrvoje Popovski
On 8.6.2022. 15:04, Jan Klemkow wrote: > Could you show me, how your setup and your configuration looks like? Yes, of course .. All my lab boxes are connected to switch (no flow-control). In this setup ix0 and ix1 are in aggr and vlans 700 and 800 are tagged on aggr3. I have tried tcpbench and ip

m4: gnu-m4 compat draft

2022-06-08 Thread Marc Espie
Naddy told me about an app that wants a gnu-m4 extension that requires >9 arguments to macros. I wrote a very quick patch that seems to do the work. There are probably lots of kinks to work out, it's been very lightly tested. (in particular, I haven't looked at stuff like $* and friends yet, mayb

Re: bgpd: refactor kroute code a fair bit

2022-06-08 Thread Claudio Jeker
On Wed, Jun 08, 2022 at 06:10:21PM +0200, Theo Buehler wrote: > On Wed, Jun 08, 2022 at 01:28:14PM +0200, Claudio Jeker wrote: > > The idea behind this diff is to use struct kroute_full in more places. > > Mainly when parsing route messages. This allows to factor out the pure > > route message pars

Re: bgpd: refactor kroute code a fair bit

2022-06-08 Thread Theo Buehler
On Wed, Jun 08, 2022 at 01:28:14PM +0200, Claudio Jeker wrote: > The idea behind this diff is to use struct kroute_full in more places. > Mainly when parsing route messages. This allows to factor out the pure > route message parsing into dispatch_rtmsg_addr() and use it in both the > gerneral routi

Re: set RTF_DONE in sysctl_dumpentry for the routing table

2022-06-08 Thread Martin Pieuchot
On 08/06/22(Wed) 16:13, Claudio Jeker wrote: > Notice while hacking in OpenBGPD. Unlike routing socket messages the > messages from the sysctl interface have RTF_DONE not set. > I think it would make sense to set RTF_DONE also in this case since it > makes reusing code easier. > > All messages sen

set RTF_DONE in sysctl_dumpentry for the routing table

2022-06-08 Thread Claudio Jeker
Notice while hacking in OpenBGPD. Unlike routing socket messages the messages from the sysctl interface have RTF_DONE not set. I think it would make sense to set RTF_DONE also in this case since it makes reusing code easier. All messages sent out via sysctl_dumpentry() have been processed by the k

bgpd: refactor kroute code a fair bit

2022-06-08 Thread Claudio Jeker
The idea behind this diff is to use struct kroute_full in more places. Mainly when parsing route messages. This allows to factor out the pure route message parsing into dispatch_rtmsg_addr() and use it in both the gerneral routing socket code but also in fetchtables(). Which removes some duplicated