W dniu 7.06.2024 o 15:55, Zhenlei Huang pisze:
As discussed with Marek in Telegram, those looks pretty safe to MFC. I can do
the MFC if no explicit objections.
Great to hear !
--
Marek Zarychta
> On Jun 7, 2024, at 4:10 PM, Marek Zarychta
> wrote:
>
> Invaluable Committers, Dear Subscribers,
>
> I found Gleb's fixes to ICMP6 error rate limiting extremely useful,
> especially since this limiting is not working at all in stable/14 (as far as
> I was able to test). It looks to me
Hi Ed
On Thu, 06 Jun 2024 02:48:36 +0100 Ed Maste wrote ---
> On Sun, 7 Aug 2022 at 01:32, Ben Woods woods...@freebsd.org> wrote:
> In the previous threads some objections were raised about dhcpcd's
> lack of sandboxing (Capsicum / privilege separation), which has since
> been
Hi,
using tap with bhyve when I reboot an instance but the tap8 does not get
destroyed but re-used it loses it's IPv6 link-local address and as bhyve
starts again (remote end comes up) it doesn't come back.
I have to manually toggle tap8 down, tap8 up to get the IPv6 link-locla
back. Anyone
On Wed, 22 May 2024, Zhenlei Huang wrote:
On May 22, 2024, at 12:17 PM, Bjoern A. Zeeb
wrote:
Hi,
sorry, I cannot dump; this is a diskless and netdump does not do IPv6;
needless to say that would be funny in this case anyway; unfortunately
I have also already re-compiled the kernel so I
> On May 22, 2024, at 12:17 PM, Bjoern A. Zeeb
> wrote:
>
> Hi,
>
> sorry, I cannot dump; this is a diskless and netdump does not do IPv6;
> needless to say that would be funny in this case anyway; unfortunately
> I have also already re-compiled the kernel so I
On 5/20/2024 11:54 AM, Mike Karels wrote:
That sounds like an outright bug. Looks like it was true in 14.0 as well.
Is there a bug report? I couldn't find one.
I didnt open one. Wasnt sure if it the change was a deliberate one or on the
wrong side of POLA. To me it feels unnecessary to have
On 20 May 2024, at 10:15, mike tancsa wrote:
> On 5/19/2024 8:59 PM, Mike Karels wrote:
>> On 19 May 2024, at 18:29, mike tancsa wrote:
>>
>>> On 5/18/2024 10:49 AM, Mike Karels wrote:
I have no networking changes at all in the 14.1 release notes. Is there
anything that should be
On 5/19/2024 8:59 PM, Mike Karels wrote:
On 19 May 2024, at 18:29, mike tancsa wrote:
On 5/18/2024 10:49 AM, Mike Karels wrote:
I have no networking changes at all in the 14.1 release notes. Is there
anything that should be mentioned? Feel free to reply to me individually.
Not sure if
John I vote for importing intels man page provided with the source . It’s better then nothing.---Mark Saad | nones...@longcount.orgOn May 20, 2024, at 12:36 AM, John Hay wrote:Hi Mike,The ice(4) driver for Intel E800 Ethernet controllers has been in the tree since May 2020, but it seems it was
Hi Mike,
The ice(4) driver for Intel E800 Ethernet controllers has been in the tree
since May 2020, but it seems it was never added to the release notes. It
also does not have a man page. There is a bug report for the missing man
page:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262892
On 19 May 2024, at 18:29, mike tancsa wrote:
> On 5/18/2024 10:49 AM, Mike Karels wrote:
>> I have no networking changes at all in the 14.1 release notes. Is there
>> anything that should be mentioned? Feel free to reply to me individually.
>>
> Not sure if appropriate or not, but when going to
On 5/18/2024 10:49 AM, Mike Karels wrote:
I have no networking changes at all in the 14.1 release notes. Is there
anything that should be mentioned? Feel free to reply to me individually.
Not sure if appropriate or not, but when going to 13.x to 14.x, not all
vlan configs work now in rc.conf
<>
That's been a very workable system.
p vixie
On May 17, 2024 21:32, "Rodney W. Grimes" wrote:
> Scott writes:
> > Anyway, fun's over. Perhaps this is a greater lesson that the Foundation
> > provide the rules under which code is added or removed from base and then
> > we'd all be
> Scott writes:
> > Anyway, fun's over. Perhaps this is a greater lesson that the Foundation
> > provide the rules under which code is added or removed from base and then
> > we'd all be the wiser.
>
> The FreeBSD Foundation does not set project policy, the FreeBSD Core
> Team does.
Sadly
Scott writes:
> Anyway, fun's over. Perhaps this is a greater lesson that the Foundation
> provide the rules under which code is added or removed from base and then
> we'd all be the wiser.
The FreeBSD Foundation does not set project policy, the FreeBSD Core
Team does.
DES
--
Dag-Erling
Scott:
> I'm never sure whether to respond to sophistry and rhetoric, but why not,
> let's play:
my intention with this post was not to engage in sophistry, but to
explain (or justify) the reasoning behind my proposal to remove
RIP/RIPng, since you seemed to be asking for more details on that.
i
On Thu, May 16, 2024 at 02:02:52PM +0100, Lexi Winter wrote:
> Scott:
> > I use RIPv2 for it's simplicity and small memory and CPU requirements. It
> > has its place and shouldn't be considered "legacy" despite its
> > shortcomings.
> > It's not uncommon for vendors like Cisco to produce
On Thu, May 16, 2024 at 3:03 PM Lexi Winter wrote:
> (..)
> almost anything would be useful for someone, somewhere. for example,
> i'd quite like to see a basic Wayland compositor (such as hikari) and a
> terminal emulator in the base system, because that's a bit nicer to use
> than vt(4) if you
Scott:
> I use RIPv2 for it's simplicity and small memory and CPU requirements. It
> has its place and shouldn't be considered "legacy" despite its shortcomings.
> It's not uncommon for vendors like Cisco to produce "basic" feature sets of
> IOS that do not include any link-state protocols.
, and not
the only one for the community.
take deep breaths.
re:
John Howie wrote on 2024-05-15 19:04:
FreeBSD (and BSD Unix in general) has a rich history of being a
“complete” OS – kernel and userland. If there was really a demand for a
minimalist version of FreeBSD, why have people not forked FreeBSD
installs (yes, I
know it is meant for embedded systems, but it works).
I think we need to stop trying to find solutions for non-existent problems.
From: owner-freebsd-...@freebsd.org on behalf
of Marek Zarychta
Date: Wednesday, May 15, 2024 at 11:19 AM
To: freebsd-net@freebsd.org
Subject: Re
Today Michael Sierchio wrote:
There is an argument to be made that all such components of the "base"
system should be packages, and managed that way. That would
facilitate removal or addition of things like MTAs, Route daemons for
various protocols, etc. and permit them to be updated
There is an argument to be made that all such components of the "base"
system should be packages, and managed that way. That would facilitate
removal or addition of things like MTAs, Route daemons for various
protocols, etc. and permit them to be updated independent of the base
system. Too much
I use RIP all the time. Removing it would be a pain. What is the justification?
Moving it to ports is an option, but now we have to compile, distribute, and
install it.
Sent from my iPhone
> On May 15, 2024, at 07:40, Tomek CEDRO wrote:
>
> On Wed, May 15, 2024 at 4:20 PM Scott wrote:
>>>
On Wed, May 15, 2024 at 4:20 PM Scott wrote:
> On Mon, Apr 15, 2024 at 09:49:27PM +0100, Lexi Winter wrote:
> > (..)
> > i'd like to submit a patch to remove both of these daemons from src. if
> > there's some concern that people still want to use the BSD
> > implementation of routed/route6d,
On Mon, Apr 15, 2024 at 09:49:27PM +0100, Lexi Winter wrote:
> [note: this is a copy of a mail i sent this to arch@, but someone
> suggested also asking net@ about this.]
>
> hello,
>
> currently FreeBSD ships routed(8) and route6d(8) which implement the RIP
> resp. RIPng routing protocols.
>
>
On Tue, 7 May 2024 at 14:35, Marek Zarychta
wrote:
>
> But what about IPv6 ? We have "net.inet6.icmp6.rediraccept" knob which
> defaults to 1. Can ICMPv6 redirects be fixed along with the change
> proposed for the legacy IP protocol?
It may make sense to apply the same default change for IPv6,
W dniu 7.05.2024 o 20:12, Ed Maste pisze:
I propose that we start dropping inbound ICMP REDIRECTs by default, by
setting the net.inet.icmp.drop_redirect sysctl to 1 by default (and
changing the associated rc.conf machinery). I've opened a Phabricator
review at https://reviews.freebsd.org/D45102.
I'll remind everybody that ifconfig has had IFCONFIG_FORMAT since
```
commit 7c2aa744374aa3449ad81f60852e74ad73d823e6
Author: Allan Jude
Date: Tue May 31 17:30:08 2016 +
ifconfig(8) now supports some output formatting options
```
so we've already 7 years into this process. This is
This is what I did :
on FreeBSD :
/etc/rc.conf :
ifconfig_em0="inet 192.168.1.5 netmask 255.255.255.0"
defaultrouter="192.168.1.10"
On Ubuntu :
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -A PREROUTING -t nat -p tcp -d 192.168.1.10 -j DNAT
--to-destination 192.168.1.5
iptables -A
Jessica Clarke:
> On 4 May 2024, at 16:34, Lexi Winter wrote:
> Do we need to care about supporting (/ do we currently support)
> historical non-contiguous netmasks? At a glance the CIDR code doesn’t
> handle that and will stop at the first 0, so changing to that by
> default would break such
On 4 May 2024, at 16:34, Lexi Winter wrote:
> hi,
>
> i've just submitted this PR:
>
> https://github.com/freebsd/freebsd-src/pull/1216
>
> which contains this commit:
>
> commit 57d273c90ee1c17446236aba25ed0bd291c4f126 (HEAD -> lf/main,
> hemlock/lf/main)
> Author: Lexi Winter
> Date:
So. Please help me further...
Let's say that the IP number assigned to Ubuntu is 192.168.1.9,on FreeBSD I
do :
/etc/rc.conf :
defaultrouter="192.168.1.9"
? even if the VM starts after the booting of FreeBSD ?
About configuring the DNAT iptables rule I have no idea. Please help me to
Hi Mario
You can set the ip if the Ubuntu machine as the default route on the
freeBSD host.
This will take all the traffic oroginating in freeBSD host through the
warp-tunnel.
And configure a DNAT iptables rule in the Ubuntu machine to return the
traffic back to freeBSD machine.
This way you
On 26 Apr 2024, at 23:02, Bakul Shah wrote:
> On Apr 26, 2024, at 8:41 PM, Warner Losh wrote:
>>
>>
>>
>> On Fri, Apr 26, 2024, 9:33 PM Bakul Shah wrote:
>>
>>
>>> On Apr 26, 2024, at 5:02 PM, Mike Karels wrote:
>>>
>>> On 26 Apr 2024, at 18:06, Warner Losh wrote:
>>>
On Fri, Apr 26, 2024
On Apr 26, 2024, at 8:41 PM, Warner Losh wrote:
>
>
>
> On Fri, Apr 26, 2024, 9:33 PM Bakul Shah wrote:
>
>
> > On Apr 26, 2024, at 5:02 PM, Mike Karels wrote:
> >
> > On 26 Apr 2024, at 18:06, Warner Losh wrote:
> >
> >> On Fri, Apr 26, 2024 at 4:21 PM Mike Karels wrote:
> >>
> >>> On
On Fri, Apr 26, 2024, 9:33 PM Bakul Shah wrote:
>
>
> > On Apr 26, 2024, at 5:02 PM, Mike Karels wrote:
> >
> > On 26 Apr 2024, at 18:06, Warner Losh wrote:
> >
> >> On Fri, Apr 26, 2024 at 4:21 PM Mike Karels wrote:
> >>
> >>> On 26 Apr 2024, at 15:49, Mike Karels wrote:
> >>>
> On 26
> On Apr 26, 2024, at 5:02 PM, Mike Karels wrote:
>
> On 26 Apr 2024, at 18:06, Warner Losh wrote:
>
>> On Fri, Apr 26, 2024 at 4:21 PM Mike Karels wrote:
>>
>>> On 26 Apr 2024, at 15:49, Mike Karels wrote:
>>>
On 26 Apr 2024, at 15:01, Warner Losh wrote:
> This has to be a
On 26 Apr 2024, at 18:06, Warner Losh wrote:
> On Fri, Apr 26, 2024 at 4:21 PM Mike Karels wrote:
>
>> On 26 Apr 2024, at 15:49, Mike Karels wrote:
>>
>>> On 26 Apr 2024, at 15:01, Warner Losh wrote:
>>>
This has to be a FAQ
I'm porting a program from Linux, I often see an error
On Fri, Apr 26, 2024 at 4:21 PM Mike Karels wrote:
> On 26 Apr 2024, at 15:49, Mike Karels wrote:
>
> > On 26 Apr 2024, at 15:01, Warner Losh wrote:
> >
> >> This has to be a FAQ
> >>
> >> I'm porting a program from Linux, I often see an error like:
> >> ./test/mock-ifaddrs.c:95:19: error: no
On 26 Apr 2024, at 15:49, Mike Karels wrote:
> On 26 Apr 2024, at 15:01, Warner Losh wrote:
>
>> This has to be a FAQ
>>
>> I'm porting a program from Linux, I often see an error like:
>> ./test/mock-ifaddrs.c:95:19: error: no member named 's6_addr32' in 'struct
>> in6_addr'
>>95 |
On 26 Apr 2024, at 15:01, Warner Losh wrote:
> This has to be a FAQ
>
> I'm porting a program from Linux, I often see an error like:
> ./test/mock-ifaddrs.c:95:19: error: no member named 's6_addr32' in 'struct
> in6_addr'
>95 | ipv6->sin6_addr.s6_addr32[3] = 0;
> |
On 25 Apr 2024, at 15:56, Gregory Shapiro wrote:
>> of course, gethostid(3) is now deprecated in favour of sysctl(3), and the
>> hostid(8) command is gone, and there's now more than one flavour of
>> Internet-capable UNIX in the world, and there's more than one Internet
>> address family now. so
> > of course, gethostid(3) is now deprecated in favour of sysctl(3), and the
> > hostid(8) command is gone, and there's now more than one flavour of
> > Internet-capable UNIX in the world, and there's more than one Internet
> > address family now. so what i did in 1990 is a guide only inasmuch as
> of course, gethostid(3) is now deprecated in favour of sysctl(3), and the
> hostid(8) command is gone, and there's now more than one flavour of
> Internet-capable UNIX in the world, and there's more than one Internet
> address family now. so what i did in 1990 is a guide only inasmuch as some
>
agreed. and one of my mods to the ultrix (~4.3bsd) kernel for
gatekeeper.dec.com back in ~1990 was to use the result of gethostid(3)
if that result was nonzero and if a socket was not already bound. so
named(8) and ntpd(8) and anything else that used explicit binding got
what they expected,
On 4/23/2024 10:12 PM, Gregory Shapiro wrote:
Short version:
Using FreeBSD as a BGP router has network issues caused by suboptimal
default IPv4 source address selection when connected to Internet
Exchanges (which are required to use IPs that aren't routable on the
Internet). I was hoping to
> The mistake your making, IMHO, is that an IX connected eBGP FreeBSD
> router _SHOULD NOT_ be doing ANYTHING other than BGP on the IX
> connected interface, and anything like DNS and outbound SMTP should be
> going inward on the AS, not outward to the internet.
Fair point and thank you for the
On Wed, Apr 24, 2024 at 07:10:51AM +0200, Marek Zarychta wrote:
> W dniu 24.04.2024 o 04:12, Gregory Shapiro pisze:
> > Short version:
> >
> > Using FreeBSD as a BGP router has network issues caused by suboptimal
> > default IPv4 source address selection when connected to Internet
> > Exchanges
> Short version:
>
> Using FreeBSD as a BGP router has network issues caused by suboptimal
> default IPv4 source address selection when connected to Internet
> Exchanges (which are required to use IPs that aren't routable on the
> Internet). I was hoping to find more elegant workarounds or
W dniu 24.04.2024 o 04:12, Gregory Shapiro pisze:
Short version:
Using FreeBSD as a BGP router has network issues caused by suboptimal
default IPv4 source address selection when connected to Internet
Exchanges (which are required to use IPs that aren't routable on the
Internet). I was hoping
On Wed, Apr 17, 2024 at 10:04 PM Lexi Winter wrote:
> Paul Procacci:
> > I'm assigning VF's to bhyve with pci passthru.
> [...]
> > Given this, I figured the best option would be to set the VLAN on the VF
> on
> > the host prior to handing it off to the bhyve instance effectively
> enabling
> >
Paul Procacci:
> I'm assigning VF's to bhyve with pci passthru.
[...]
> Given this, I figured the best option would be to set the VLAN on the VF on
> the host prior to handing it off to the bhyve instance effectively enabling
> transparent vlans.
[...]
> Has anyone done this? Does anyone have any
On Mon, 15 Apr 2024 at 16:49, Lexi Winter wrote:
>
> currently FreeBSD ships routed(8) and route6d(8) which implement the RIP
> resp. RIPng routing protocols.
> ...
> i'd like to submit a patch to remove both of these daemons from src. if
> there's some concern that people still want to use the
(...)
Backup server is https://www.rsync.net/ (free 500GB for FreeBSD
developers).
Nuno Teixeira escreveu (quarta, 10/04/2024 à(s)
13:39):
> With base stack I can complete restic check successfully
> downloading/reading/checking all files from a "big" remote compressed
> backup.
> Changing it
With base stack I can complete restic check successfully
downloading/reading/checking all files from a "big" remote compressed
backup.
Changing it to RACK stack, it fails.
I run this command often because in the past, compression corruption
occured and this is the equivalent of restoring backup
> On 10. Apr 2024, at 13:40, Nuno Teixeira wrote:
>
> Hello all,
>
> @ current 1500018 and fetching torrents with net-p2p/qbittorrent finished
> ~2GB download and connection UP until the end:
>
> ---
> Apr 10 11:26:46 leg kernel: re0: watchdog timeout
> Apr 10 11:26:46 leg kernel: re0:
Hello all,
@ current 1500018 and fetching torrents with net-p2p/qbittorrent finished
~2GB download and connection UP until the end:
---
Apr 10 11:26:46 leg kernel: re0: watchdog timeout
Apr 10 11:26:46 leg kernel: re0: link state changed to DOWN
Apr 10 11:26:49 leg dhclient[58810]: New IP
On Mon, 08 Apr 2024 04:16:47 +0100 Anton Yudin wrote ---
> I'm running a FreeBSD 14 with two interfaces that use DHCP. I would like
> to make one of the interfaces to never set the default route. Right now the
> first interface to be fully up sets the default route.
>
> I
On 2024-04-07 20:16, Anton Yudin wrote:
I'm running a FreeBSD 14 with two interfaces that use DHCP.
I would like to make one of the interfaces to never set the default
route.
Right now the first interface to be fully up sets the default route.
I tried to set the following in
> On 3. Apr 2024, at 19:46, Sad Clouds wrote:
>
> On Wed, 3 Apr 2024 17:28:52 +0200
> Michael Tuexen wrote:
>
>>> On 3. Apr 2024, at 15:44, Sad Clouds wrote:
>>>
>>> I found a bug that is still open from May 2010 and describes the same
>>> behaviour that I see with my application:
>>>
>>>
On Wed, 3 Apr 2024 17:28:52 +0200
Michael Tuexen wrote:
> > On 3. Apr 2024, at 15:44, Sad Clouds wrote:
> >
> > I found a bug that is still open from May 2010 and describes the same
> > behaviour that I see with my application:
> >
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=146845
> On 3. Apr 2024, at 15:44, Sad Clouds wrote:
>
> I found a bug that is still open from May 2010 and describes the same
> behaviour that I see with my application:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=146845
>
> If this hasn't been fixed over the last 14 years, then I guess I
I found a bug that is still open from May 2010 and describes the same
behaviour that I see with my application:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=146845
If this hasn't been fixed over the last 14 years, then I guess I will
add some code to simply ignore ECONNRESET on close(2) for
Thanks for the link! the VIMAGE concept is such an interesting hack..
Benoît Chesneau, Enki Multimedia
—
t. +33608655490
Sent with Proton Mail secure email.
On Thursday, March 28th, 2024 at 10:17, Tom Jones wrote:
>
> On Tue, Mar 26, 2024, at 18:31, Benoit Chesneau wrote:
>
> > How does
> On 28. Mar 2024, at 15:00, Nuno Teixeira wrote:
>
> Hello all!
>
> Running rack @b7b78c1c169 "Optimize HPTS..." very happy on my laptop (amd64)!
>
> Thanks all!
Thanks for the feedback!
Best regards
Michael
>
> Drew Gallatin escreveu (quinta, 21/03/2024 à(s) 12:58):
> The entire point is
Hello all!
Running rack @b7b78c1c169 "Optimize HPTS..." very happy on my laptop
(amd64)!
Thanks all!
Drew Gallatin escreveu (quinta, 21/03/2024 à(s)
12:58):
> The entire point is to *NOT* go through the overhead of scheduling
> something asynchronously, but to take advantage of the fact that
---> A very simple and elegant shell management tool to play with bhyve is
vm-bhyve
I never use it. I created my own elegant script that in my opinion works
better than vm-bhyve. And I think that I can improve it
I will...
On Tue, Mar 26, 2024 at 8:30 PM Tomek CEDRO wrote:
> On Tue, Mar
On Tue, Mar 26, 2024, at 18:31, Benoit Chesneau wrote:
> How does work VNET with interfaces? Is this as efficient as using pci
> passtrough in a vm ?
Overhead should be minimal, while the device is logically missing from the
default vnet there isn't any more "in the way" for actual usage.
On Tue, Mar 26, 2024 at 7:32 PM Benoit Chesneau
wrote:
> How does work VNET with interfaces? Is this as efficient as using pci
> passtrough in a vm ?
> Benoît
Vnet allows you to control networks by the system and make various
configurations networks jails etc, example here:
> On Mar 22, 2024, at 5:05 PM, Benoit Chesneau
> wrote:
>
> Awesome! Do we have a chance it land in a patch release soon ? Or better to
> use a STABLE until the 14.1 is released?
>
Or you can stay on 14.0 If the workaround can fulfill. 14.1 is about to be
released at 18 June as per the
Awesome! Do we have a chance it land in a patch release soon ? Or better to use
a STABLE until the 14.1 is released?
Benoît
On Thursday, March 14th, 2024 at 10:56, Zhenlei Huang wrote:
>> On Mar 14, 2024, at 9:04 AM, Zhenlei Huang wrote:
>>
>>> On Mar 14, 2024, at 3:07 AM, Marek Zarychta
The entire point is to *NOT* go through the overhead of scheduling something
asynchronously, but to take advantage of the fact that a user/kernel transition
is going to trash the cache anyway.
In the common case of a system which has less than the threshold number of
connections , we access
On Tue, Mar 19, 2024 at 06:19:52AM -0400, rrs wrote:
> Ok I have created
>
> https://reviews.freebsd.org/D44420
>
>
> To address the issue. I also attach a short version of the patch that Nuno
> can try and validate
>
> it works. Drew you may want to try this and validate the optimization does
No. The goal is to run on every return to userspace for every thread.
Drew
On Mon, Mar 18, 2024, at 3:41 PM, Konstantin Belousov wrote:
> On Mon, Mar 18, 2024 at 03:13:11PM -0400, Drew Gallatin wrote:
> > I got the idea from
> >
On Mon, Mar 18, 2024 at 03:13:11PM -0400, Drew Gallatin wrote:
> I got the idea from
> https://people.mpi-sws.org/~druschel/publications/soft-timers-tocs.pdf
> The gist is that the TCP pacing stuff needs to run frequently, and
> rather than run it out of a clock interrupt, its more efficient to
I got the idea from
https://people.mpi-sws.org/~druschel/publications/soft-timers-tocs.pdf The
gist is that the TCP pacing stuff needs to run frequently, and rather than run
it out of a clock interrupt, its more efficient to run it out of a system call
context at just the point where we
On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote:
> On 18 Mar 2024, at 7:04, tue...@freebsd.org wrote:
>
> >> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote:
> >>
> >> Hello all!
> >>
> >> It works just fine!
> >> System performance is OK.
> >> Using patch on
On 18 Mar 2024, at 7:04, tue...@freebsd.org wrote:
>> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote:
>>
>> Hello all!
>>
>> It works just fine!
>> System performance is OK.
>> Using patch on main-n268841-b0aaf8beb126(-dirty).
>>
>> ---
>> net.inet.tcp.functions_available:
>> Stack
> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote:
>
> Hello all!
>
> It works just fine!
> System performance is OK.
> Using patch on main-n268841-b0aaf8beb126(-dirty).
>
> ---
> net.inet.tcp.functions_available:
> Stack D AliasPCB count
>
Hello all!
It works just fine!
System performance is OK.
Using patch on main-n268841-b0aaf8beb126(-dirty).
---
net.inet.tcp.functions_available:
Stack D AliasPCB count
freebsd freebsd 0
rack
Hello,
> I don't have the full context, but it seems like the complaint is a
> performance regression in bonnie++ and perhaps other things when tcp_hpts is
> loaded, even when it is not used. Is that correct?
>
> If so, I suspect its because we drive the tcp_hpts_softclock() routine from
>
> On 17. Mar 2024, at 16:39, Drew Gallatin wrote:
>
> I don't have the full context, but it seems like the complaint is a
> performance regression in bonnie++ and perhaps other things when tcp_hpts is
> loaded, even when it is not used. Is that correct?
Correct.
>
> If so, I suspect its
Resending with the patch as an attachment.
Drew
On Sun, Mar 17, 2024, at 11:39 AM, Drew Gallatin wrote:
> I don't have the full context, but it seems like the complaint is a
> performance regression in bonnie++ and perhaps other things when tcp_hpts is
> loaded, even when it is not used. Is
I don't have the full context, but it seems like the complaint is a performance
regression in bonnie++ and perhaps other things when tcp_hpts is loaded, even
when it is not used. Is that correct?
If so, I suspect its because we drive the tcp_hpts_softclock() routine from
userret(), in order
Hello,
> > - I can't remember better tests to do as I can feel the entire OS is
> > being slow, without errors, just slow.
> This is interesting. It seems a consequence on loading TCPHPTS, not actually
> using it.
Exactly, just loading module and not using it by setting sysctl.
> I have CCed
> On 16. Mar 2024, at 21:29, Nuno Teixeira wrote:
>
>> Just to double check: you only load the tcp_rack. You don't run
>> sysctl net.inet.tcp.functions_default=rack
>
> I'm not using sysctl, just loading module.
And you also don't have
net.inet.tcp.functions_default=rack
in /etc/sysctl.conf
> Just to double check: you only load the tcp_rack. You don't run
> sysctl net.inet.tcp.functions_default=rack
I'm not using sysctl, just loading module.
> What does "poudriere testport net/gitup" do? Only build stuff or does is
> also download something?
>
> What does bonnie++ do?
poudriere is
> On 16. Mar 2024, at 20:06, Nuno Teixeira wrote:
>
>>> Will update amd64 laptop to main-n268827-75464941dc17 (Mar 16) and test it.
>> Please do so...
>
> @main-n268827-75464941dc17 GENERIC-NODEBUG amd64
>
> Ok, I think I have here some numbers related to disk performance being
> affected by
> > Will update amd64 laptop to main-n268827-75464941dc17 (Mar 16) and test it.
> Please do so...
@main-n268827-75464941dc17 GENERIC-NODEBUG amd64
Ok, I think I have here some numbers related to disk performance being
affected by tcp_rack that somehow is messing with something.
NOTES:
- test
> On 16. Mar 2024, at 15:00, Nuno Teixeira wrote:
>
>> If you load tcp_rack via kldload, tcphtps get loaded automatically.
>> If you load if via /boot/loader.conf, you need to have
>> tcphpts_load="YES"
>> in addition to
>> tcp_rack_load="YES"
>
> As of my tests, loader.conf:
> If you load tcp_rack via kldload, tcphtps get loaded automatically.
> If you load if via /boot/loader.conf, you need to have
> tcphpts_load="YES"
> in addition to
> tcp_rack_load="YES"
As of my tests, loader.conf: tcp_rack_load="YES" loads tcphtps.ko auto:
31 0x81f53000545e0
> On 16. Mar 2024, at 11:59, Nuno Teixeira wrote:
>
>>> Resuming I only need to add:
>>>
>>> options TCPHPTS
>>>
>>> Is this correct?
>>>
>>
>> Yeah, that will probably fix it. According to a comment in
>> /usr/src/sys/netinet/tcp_hpts.c it adds a high precision timer
>> system for
> > Resuming I only need to add:
> >
> > options TCPHPTS
> >
> > Is this correct?
> >
>
> Yeah, that will probably fix it. According to a comment in
> /usr/src/sys/netinet/tcp_hpts.c it adds a high precision timer
> system for tcp, used by RACK and BBR.
As tuexen said, on main,
On Sat, 16 Mar 2024 10:11:22 +
Nuno Teixeira wrote:
> (...)
>
> > These entries are missing in GENERIC:
> >
> > makeoptions WITH_EXTRA_TCP_STACKS=1
>
> From
> https://cgit.freebsd.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc
> WITH_EXTRA_TCP_STACKS was dropped.
>
> >
> On 16. Mar 2024, at 11:11, Nuno Teixeira wrote:
>
> (...)
>
>> These entries are missing in GENERIC:
>>
>> makeoptions WITH_EXTRA_TCP_STACKS=1
>
> From
> https://cgit.freebsd.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc
> WITH_EXTRA_TCP_STACKS was dropped.
>
>> options
(...)
> These entries are missing in GENERIC:
>
> makeoptions WITH_EXTRA_TCP_STACKS=1
>From
>https://cgit.freebsd.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc
WITH_EXTRA_TCP_STACKS was dropped.
> options TCPHPTS
That's the missing option in GENERIC that could lead
On Sat, 16 Mar 2024 09:49:24 +
Nuno Teixeira wrote:
> Hello Gary,
>
> Nice that you found this.
>
> tcp_tack manual doesn't mention that we need extra config in kernel
> but it loads module and it is shown in sysctl
> net.inet.tcp.functions_available without errors.
>
> I will add missing
Hello Gary,
Nice that you found this.
tcp_tack manual doesn't mention that we need extra config in kernel
but it loads module and it is shown in sysctl
net.inet.tcp.functions_available without errors.
I will add missing config to GENERIC and see how it goes.
Cheers,
Gary Jennejohn escreveu
1 - 100 of 40324 matches
Mail list logo
