[Bug 248005] nd6 initializes nd_ifinfo->maxmtu = 0 on newly inserted network interfaces
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248005 Kubilay Kocak changed: What|Removed |Added Flags|maintainer-feedback?(kp@fre |maintainer-feedback? |ebsd.org) | Keywords|needs-qa| -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
FreeBSD Users Contact List.
Hello, I would like to know if you are interested in acquiring FreeBSD Users Contact List. Information fields: Names, Title, Email, Phone, Company Name, Company URL, Company physical address, SIC Code, Industry and Specialty (Revenue and Employee). Let me know if you are interested and I will get back to you with the counts and pricing. Regards, Hailey Michelle Marketing Executive Please get back to me with your target market criteria in the subject line. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IF_DRV_PREPEND unlocked?
Marko Zec wrote this message on Thu, Jul 16, 2020 at 07:49 +0200: > On Thu, 16 Jul 2020 07:26:22 +0200 > Marko Zec wrote: > > > On Wed, 15 Jul 2020 16:26:25 -0700 > > John-Mark Gurney wrote: > > > > > I happen to be looking at the implementation of IFQ_DRV_PREPEND, and > > > unlike IFQ_DRV_DEQUEUE, it doesn't obtain the lock when manipulating > > > the ifq. I took a brief look at a few drivers, and it looks like > > > some of them expect that _PREPEND lock the Q like _DEQUEUE does. > > > > > > This is likely not an issue often, since it's an error path that > > > likely rarely happens, but we should fix it. > > > > > > Should we just add the IFQ_LOCK/_UNLOCK to the macro? > > > > > > Comments or thoughts? > > > > I also have a hard time understanding the semantics of IFQ_DRV_* > > macros: per altq(9) they appear to be variants of their IFQ_ > > counterparts which are intended to be protected by some other > > mechanism rather than IFQ_LOCK, but in some instances this isn't the > > case, as they do grab the IFQ_LOCK. > > Hmm it's not that unclear after looking better: ifq_drv_* parts of > struct ifaltq should be protected by some external mechanisms when > using IFQ_DRV_ macros, and ifq_ parts are still protected by ifq_mtx. > So it doesn't look like IFQ_LOCK/_UNLOCK should be added to > IFQ_DRV_PREPEND()... Ahh, I was miss reading the macros on what was protected. Yes, it does look like the ifq_drv_* fields are supposed to be protected by another lock... I just now found that altq(9) documents this interface... I had assumed it as undocumented after man IFQ_DRV_DEQUEUE didn't return results.. Looks like I REALLY do need to complete my script to make sure that ALL Nm's and related pages have MLINKs. ALTQ.9 is missing 16 links to the functions it documents... Just as a reminder to people who write docs, please, make sure you link ALL of the function in your docs... Otherwise your docs won't be as easy to find.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Deadlocks when using pf tags or socket owner matching
On 10 Jul 2020, at 22:29, Kristof Provost wrote: On 8 Jul 2020, at 12:52, Kajetan Staszkiewicz wrote: I have forgot to mention my system: it's FreeBSD 11.3-RELEASE-p9 I have also managed to replicate this (or a similar) issue on a test system built with lock debugging and I got this: Jul 8 10:32:07 hwlb-aw-01 kernel: lock order reversal: Jul 8 10:32:07 hwlb-aw-01 kernel: 1st 0x81850760 pf rulesets (pf rulesets) @ /usr/home/kajetan.staszkiewicz/freebsd.git/sys/netpfil/pf/pf.c:6006 Jul 8 10:32:07 hwlb-aw-01 kernel: 2nd 0xf8011f7028a8 tcpinp (tcpinp) @ /usr/home/kajetan.staszkiewicz/freebsd.git/sys/netinet/in_pcb.c:1994 This lock order reversal is almost certainly the reason for the deadlock you report in your previous e-mail. The problem relates to the UID filtering functionality, so not using that feature will avoid the deadlock. I believe I’ve seen previous reports about issues in this area as well. I’ll try to put this on my short-sh term todo list, but I can’t promise anything. Free time is exceptionally rare these days. I can’t seem to reproduce the LOR (or the deadlock). Can you share a minimal ruleset that triggers this problem? Thanks, Kristof ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 248005] nd6 initializes nd_ifinfo->maxmtu = 0 on newly inserted network interfaces
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248005 Kyle Evans changed: What|Removed |Added Flags|maintainer-feedback?(kevans |maintainer-feedback+ |@freebsd.org) | -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 248005] nd6 initializes nd_ifinfo->maxmtu = 0 on newly inserted network interfaces
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248005 --- Comment #2 from commit-h...@freebsd.org --- A commit references this bug: Author: kevans Date: Thu Jul 16 13:37:32 UTC 2020 New revision: 363244 URL: https://svnweb.freebsd.org/changeset/base/363244 Log: ether_ifattach: set mtu before calling if_attach() if_attach() -> if_attach_internal() will call if_attachdomain1(ifp) any time an ethernet interface is setup *after* SI_SUB_PROTO_IFATTACHDOMAIN/SI_ORDER_FIRST. This eventually leads to nd6_ifattach() -> nd6_setmtu0() stashing off ifp->if_mtu in ndi->maxmtu *before* ifp->if_mtu has been properly set in some scenarios, e.g., USB ethernet adapter plugged in later on. For interfaces that are created in early boot, we don't have this issue as domains aren't constructed enough for them to attach and thus it gets deferred to domainifattach at SI_SUB_PROTO_IFATTACHDOMAIN/SI_ORDER_SECOND *after* the mtu has been set earlier in ether_ifattach(). PR: 248005 Submitted by: Mathew MFC after:1 week Changes: head/sys/net/if_ethersubr.c -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Sales Pipeline
Hi, My name is Alex Miller and I am from the Database and Lists Management Company. I wanted to check if you are in practice of purchasing updated database? We can help you in reaching C-level decision makers, Business decision makers, Healthcare Professionals and many more across the Globe. Specific Records: All C-level executives All Key decision makers IT Executives Inventory Profession Based Index Industry Specific Records, Etc. Consumer Index: All adult age community people [age 18+]: 42M+ data All High net worth Individuals: 2.6M+ data Geography: USA, Canada, UK, Europe, Australia, Asia-Pacific etc. Please let me know your Interested Industry, Executive Job role, Geographical location you wish to reach, So that we can get back to you with the total no of records and pricing info for your review. If you are not the right point of contact, please guide this to the appropriate person. Regards, Alex Miller If you do not wish to receive any further notification from us, reply back with Leave-Out ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: poor performance with Intel X520 card
16.07.2020 16:03, Eugene Grosbein wrote: > 16.07.2020 14:57, Patrick Lamaiziere wrote: > >>> I'm sure pf is the bottle-neck. Try testing such card without any >>> packet filter enabled and you'll see great difference definitely. >> >> That's not a good news as I don't see how to simplify the ruleset :( >> But thanks anyway :) ix0: netmap queues/slots: TX 8/2048, RX 8/2048 Also, there are no reasons to use default rxd/txd slot values (2048), you should max it out with /boot/loader.conf, too: hw.ix.rxd=4096 hw.ix.txd=4096 Assuming you run 64 bit system with 1GB memory or more. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: poor performance with Intel X520 card
16.07.2020 14:57, Patrick Lamaiziere wrote: >> I'm sure pf is the bottle-neck. Try testing such card without any >> packet filter enabled and you'll see great difference definitely. > > That's not a good news as I don't see how to simplify the ruleset :( > But thanks anyway :) First, you need to determine if all your CPU cores loaded evenly or not. Use top -SHPI to check it out. It's possible that they are not because defaults could be not optimal for your hardware and you have bottle-neck just because of wrong settings for hardware receiving queues of the NIC: FreeBSD/SMP: 2 package(s) x 6 core(s) ix0: Using MSI-X interrupts with 9 vectors This means 8 RX/TX queues (plus one link queue) for your 12 cores, not good. 8 is driver's default for systems with 8 cores or more unless you override it with hw.ix.num_queues=12 in /boot/loader.conf, do it. Also you should monitor interrupt counters for receiving queues for the card with "systat -vm 3" (in real time) and with vmstat -ai | grep ix0 (cumulative). If you have interrupts evenly distributed over receiving queues but still uneven CPU cores load, that would be next problem to deal with. Maybe you'll need to (re-)bind queues to cores with cpuset(1). Or maybe your received queues are loaded not evenly due to nature of Ethernet frames you work with, f.e. non-IP ethernet traffic (PPPoE frames) or many non-TCP/UDP IP packets (GRE, ESP etc.) cpuset will be your friend for that case, too. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: poor performance with Intel X520 card
On 16 Jul 2020, at 9:57, Patrick Lamaiziere wrote: On Wed, 15 Jul 2020 17:07:23 +0700 Eugene Grosbein wrote: Hello, That is mostly for the record but it looks like the intel X520 is not very good and generates a high level of interrupts. On a router / firewall with 500 Kpps in input (dropped by pf) is enough to put the CPUs at 100% busy. [skip] Well, do you think another NIC cards can help to reach a better pps rate ? I think 500 Kpps is quite low for such a machine. I'm sure pf is the bottle-neck. Try testing such card without any packet filter enabled and you'll see great difference definitely. That's not a good news as I don't see how to simplify the ruleset :( But thanks anyway :) I’d strongly recommend that you look at Olivier’s recommended tools (specifically pmcstat) to try to diagnose the bottleneck. I see no reason to assume this must be pf (it’s possible, but I see no specific evidence for it). On this hardware I’d expect pf to be able to push around 3.5Mpps. Even a single core system (or in a situation where you end up with a lock of lock contention) it should be able to do 1.5-1.8Mpps. Best regards, Kristof ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: poor performance with Intel X520 card
On Wed, 15 Jul 2020 17:07:23 +0700 Eugene Grosbein wrote: Hello, > > That is mostly for the record but it looks like the intel X520 is > > not very good and generates a high level of interrupts. > > > > On a router / firewall with 500 Kpps in input (dropped by pf) is > > enough to put the CPUs at 100% busy. > > [skip] > > > Well, do you think another NIC cards can help to reach a better pps > > rate ? I think 500 Kpps is quite low for such a machine. > > I'm sure pf is the bottle-neck. Try testing such card without any > packet filter enabled and you'll see great difference definitely. That's not a good news as I don't see how to simplify the ruleset :( But thanks anyway :) Regards, ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [Differential] D25681: if_spppsubr: Define a few LCP options, Recognize (but still reject) multilink PPP config options
16.07.2020 14:12, lutz_donnerhacke.de (Lutz Donnerhacke) wrote: > > ce(4) for PCI G.703/E1 card, > > cp(4) for PCI V.35/RS-232/RS-530/RS-449/X.21/G.703/E1/E3/T3/STS-1 cards, > > and cx(4)/ctau(4) for some ISA cards but these do not exist in FreeBSD 13 > anymore, > > removed by emaste@ recently. > > > > Both ce(4) and cp(4) are i386-only drivers at present. > > Such synchronous lines are still in use (here): > > - G.703 is common in phone systems. > - X.21 for leased lines (with old contracts), > - E1/E3 for SDH (carrier grade) leases lines. > - RS-232 is the ordinary serial port, the other RS- are industry specific > serials (mainly other voltages) This is not about lines and protocols, this is about old PCI cards for PCs manufactured 15+ years ago. > But you are right: Do we really need a specialized PPP hardware support > these days? > Do we really want to run a recent kernel on this antique hardware? It would > be a sacrilege. > > Normal PPP over serial lines (currently available) does work using ppp(4) ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] D25681: if_spppsubr: Define a few LCP options, Recognize (but still reject) multilink PPP config options
eugen_grosbein.net removed subscribers: freebsd-net-list, emaste. eugen_grosbein.net added a comment. Sorry for the mess, my latest actions on this differential were unintentional, some problems with old Firefox. REPOSITORY rS FreeBSD src repository CHANGES SINCE LAST ACTION https://reviews.freebsd.org/D25681/new/ REVISION DETAIL https://reviews.freebsd.org/D25681 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: eugen_grosbein.net, neel_neelc.org Cc: eugen_grosbein.net, imp, ae, melifaro, #contributor_reviews_base, #network, #transport, mmacy, kpraveen.lkml_gmail.com, marcnarc_gmail.com, simonvella_gmail.com, novice_techie.com, christianchristensen_gmail.com, tommi.pernila_iki.fi, freebsd-net-list, emaste, krzysztof.galazka_intel.com ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] D25681: if_spppsubr: Define a few LCP options, Recognize (but still reject) multilink PPP config options
eugen_grosbein.net reclaimed this revision. REPOSITORY rS FreeBSD src repository CHANGES SINCE LAST ACTION https://reviews.freebsd.org/D25681/new/ REVISION DETAIL https://reviews.freebsd.org/D25681 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: eugen_grosbein.net, neel_neelc.org Cc: eugen_grosbein.net, freebsd-net-list, emaste, imp, ae, melifaro, #contributor_reviews_base, #network, #transport, mmacy, kpraveen.lkml_gmail.com, marcnarc_gmail.com, simonvella_gmail.com, novice_techie.com, christianchristensen_gmail.com, tommi.pernila_iki.fi, krzysztof.galazka_intel.com ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] D25681: if_spppsubr: Define a few LCP options, Recognize (but still reject) multilink PPP config options
eugen_grosbein.net commandeered this revision. eugen_grosbein.net added a reviewer: neel_neelc.org. REPOSITORY rS FreeBSD src repository CHANGES SINCE LAST ACTION https://reviews.freebsd.org/D25681/new/ REVISION DETAIL https://reviews.freebsd.org/D25681 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: eugen_grosbein.net, neel_neelc.org Cc: eugen_grosbein.net, freebsd-net-list, emaste, imp, ae, melifaro, #contributor_reviews_base, #network, #transport, mmacy, kpraveen.lkml_gmail.com, marcnarc_gmail.com, simonvella_gmail.com, novice_techie.com, christianchristensen_gmail.com, tommi.pernila_iki.fi, krzysztof.galazka_intel.com ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Successful project comes from a professional team
Hello Dear
I hope this email bring you a pleasant day.
This is Janice from CCJK, an ISO and ATA certified translation company in Asia.
We would be glad to offer you our professional services for the translation job
which you may need in your industy.
There are more than 6000 professional translators all over the world, 120
different languages combination, 800 faithful clients. Very cheap and quality
work supplying is our moral target. Our team members have high quality skills
and higher degrees certificate holder. We can make sure you will be 100%
satisfied and would love to hire us again. We are here to provide you our
service for 24 hours without any limitations and delivery on time.
Our translation service includes certificates,manuals, websites, contract or
other documents translation.
As a language service provider, we have translated certain projects for these
companies: such as Apple Inc., Microsoft, HUAWEI, etc.
If you have any query, we will be more than happy to provide you our quick
assistance.
Look forward to hearing from you. Thank you.
Best regards
Janice Chen| Account Manager|CCJK.com
E-mail: janice.c...@aliyun.com|Mobile: +86 15622319568| Skpe:janicechen
Translation | Localization | DTP | Subtitling | Voiceover | E-Learning
ISO 9001: 2008 | EN 17100: 2015, EN 15038: 2006 Certified|Language and IT
Services provider
This is an advertising message from CCJK Technologies Co., Ltd ("CCJK"), Rm
317, KingOne Buildling, No.20 North of Nanhai Avenue, Nanhai District, Foshan,
Guangdong, 528253 China. If you'd prefer not to receive e-mail like this from
CCJK in the future, please click here .
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 166724] if_re(4): watchdog timeout
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724 --- Comment #67 from Alex Dupre --- I've commited the vendor driver to the ports tree, with additional improvements and instructions to load it with the stock GENERIC kernel: https://svnweb.freebsd.org/ports?view=revision=542324 Thanks to kib for his support. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [Differential] D25681: if_spppsubr: Define a few LCP options, Recognize (but still reject) multilink PPP config options
CCing Roman Kurakin (ce(4)) and Serge Vakulenko (cp(4)), see later. 16.07.2020 9:23, neel_neelc.org (Neel Chauhan) wrote: > neel_neelc.org abandoned this revision. > > REPOSITORY > rS FreeBSD src repository > > CHANGES SINCE LAST ACTION > https://reviews.freebsd.org/D25681/new/ > > REVISION DETAIL > https://reviews.freebsd.org/D25681 I wonder if we really have use cases for sppp(4)/ng_sppp(4) these days. This code was created in 199x to support some synchronous Cronyx adapters and their drivers: ce(4) for PCI G.703/E1 card, cp(4) for PCI V.35/RS-232/RS-530/RS-449/X.21/G.703/E1/E3/T3/STS-1 cards, and cx(4)/ctau(4) for some ISA cards but these do not exist in FreeBSD 13 anymore, removed by emaste@ recently. Both ce(4) and cp(4) are i386-only drivers at present. I could not find any other consumers of sppp code in base system and I doubt there are outside base, but I may be wrong. I'd like to see some comments from rik and vak, though. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
