| Bonita Montero <Bonita.Montero@gmail.com>: Jul 05 05:26AM +0200 Am 04.07.2023 um 19:08 schrieb Scott Lurndal: >> And which NIC supports that ? > Start with the ubiquitous Intel E-1000 and pretty much > every other Intel pro NIC. The NICs have Task offloading for IP- and TCP Checksum calculation. Bu they for sure don't manage streams ! And interrupt routing isn't done by the NIC. > Most modern server NICs support some form of RSS. > Cheap-ass consumer gear (realtek, etc) - you get what you pay for. Linux doesn't use task offloading according to this: https://en.wikipedia.org/wiki/TCP_offload_engine |
| Bonita Montero <Bonita.Montero@gmail.com>: Jul 05 05:28AM +0200 Am 04.07.2023 um 19:25 schrieb Frederick Virchanza Gotham: > Ethernet header is 14 bytes, and the IP packet was 44 bytes, bringing the incoming frame to 58 bytes. So the operating system / network card tagged two zero bytes on the end. > I was debugging it for approx 8 hours before I figured out what was wrong. Now I'm lost losing any packets. > Still though I just set the 'priority' of my network reading thread to maximum. Why do you do the checksum-stuff yourself ? |
| Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Jul 05 01:54AM -0700 On Wednesday, July 5, 2023 at 4:28:22 AM UTC+1, Bonita Montero wrote: > Why do you do the checksum-stuff yourself ? My program opens a raw socket and does port scanning. I last released a version about 14 years ago: ( http://www.virjacode.com/projects/dynamo/ ), and I hope to release a new version with way more features this year. |
| Vir Campestris <vir.campestris@invalid.invalid>: Jul 05 12:13PM +0100 On 04/07/2023 18:25, Frederick Virchanza Gotham wrote: > Ethernet header is 14 bytes, and the IP packet was 44 bytes, bringing the incoming frame to 58 bytes. So the operating system / network card tagged two zero bytes on the end. > I was debugging it for approx 8 hours before I figured out what was wrong. Now I'm lost losing any packets. > Still though I just set the 'priority' of my network reading thread to maximum. Thanks for letting us know. You've also just shown me how out of date I am in HW knowledge - last time I looked a device only had one interrupt line :( So in fact you never were losing packets at the HW level, you were throwing them away because you thought they were bad! Andy |
| Bonita Montero <Bonita.Montero@gmail.com>: Jul 05 01:43PM +0200 Am 05.07.2023 um 10:54 schrieb Frederick Virchanza Gotham: > My program opens a raw socket and does port scanning. I last released a version about 14 years ago: ( http://www.virjacode.com/projects/dynamo/ ), and I hope to release a new version with way more features this year. I don't see much sense in that. If you scan a external port range you need your own IP as the sender's address to get replies. And if you do it that way you could use normal sockets. |
| Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Jul 05 06:28AM -0700 On Wednesday, July 5, 2023 at 12:43:19 PM UTC+1, Bonita Montero wrote: > port range you need your own IP as the sender's address > to get replies. And if you do it that way you could use > normal sockets. I suppose I could use normal sockets but I don't want the overhead of the operating system managing tens of thousands (yes, tens of thousands) of sockets and managing the 3-way handshakes for all those sockets. It's a lot more efficient to use a raw socket to send a byte-by-byte hand-crafted TCP SYN packet to each host, from port numbers 1 through 49151. |
| scott@slp53.sl.home (Scott Lurndal): Jul 05 01:49PM >The NICs have Task offloading for IP- and TCP Checksum calculation. >Bu they for sure don't manage streams ! And interrupt routing isn't >done by the NIC. Your ignorance is showing. My company makes NICs. Very powerful NICs. Which manage streams (the programmable TCAMs allow software to select the packet fields that get CAMd when selecting the target CPU for the interrupt). Most use PCI/PCIe MSI-X interrupts, which have a 32-bit payload field allowing (depending on the host interrupt controller) up to 2^32 different interrupt vectors. Our system support 21 bit payloads, supporting 2^21 physical interrupts _per_ virtual device using the ARM GIC-700 interrupt controller. Using SR-IOV allows direct shared, but mediated, access to the NIC from guest operating systems. >> Cheap-ass consumer gear (realtek, etc) - you get what you pay for. >Linux doesn't use task offloading according to this: >https://en.wikipedia.org/wiki/TCP_offload_engine That's also incorrect. Take a look at DPDK or ODP. |
| scott@slp53.sl.home (Scott Lurndal): Jul 05 01:55PM >Thanks for letting us know. You've also just shown me how out of date I >am in HW knowledge - last time I looked a device only had one interrupt >line :( Most modern high throughput devices use message signaled interrupts (MSI or MSI-X); MSI-X has a 32-bit payload field, allowing up to four billion distinct interrupt "lines". With interrupt virtualization, each guest operating system has its own 32-bit interrupt namespace, allowing an infinite number of interrupt "lines". The days of sharing level sensitive interrupts are long gone, except for supporting legacy hardware. >So in fact you never were losing packets at the HW level, you were >throwing them away because you thought they were bad! Or RED kicked in. https://en.wikipedia.org/wiki/Random_early_detection |
| Bonita Montero <Bonita.Montero@gmail.com>: Jul 05 05:05PM +0200 Am 05.07.2023 um 15:28 schrieb Frederick Virchanza Gotham: > I suppose I could use normal sockets but I don't want the overhead of the operating system managing tens of thousands (yes, tens of thousands) of sockets and managing the 3-way handshakes for all those sockets. ... These information is hashed and the time for the lookup is O(1). |
| Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Jul 05 03:04PM -0700 On Wednesday, July 5, 2023 at 4:05:24 PM UTC+1, Bonita Montero wrote: > Am 05.07.2023 um 15:28 schrieb Frederick Virchanza Gotham: > > I suppose I could use normal sockets but I don't want the overhead of the operating system managing tens of thousands (yes, tens of thousands) of sockets and managing the 3-way handshakes for all those sockets. ... > These information is hashed and the time for the lookup is O(1). Yeah but we're talking 40,000 file descriptors for one process. |
| David Brown <david.brown@hesbynett.no>: Jul 05 09:50AM +0200 On 04/07/2023 18:33, Kalevi Kolttonen wrote: > Linux could indeed become "a certified UNIX" > by fulfilling certain technical requirements: > https://www.opengroup.org/certifications/unix I was under the impression that the classification "UNIX" was for OS's that were derived from at least part of the original "UNIX" code - as was the case for SunOS, AIX, and so on. I could be wrong - or it could also have been changed. Ultimately, "UNIX" means what the owners of that trademark decide it means, and the owners have changed over time. > The Linux community never bothered to do that. The history of the term "UNIX" has been filled with politics, legal battles, economic fights - things that most of the Linux community would prefer to stay clear of. In particular, there was that ugly business with Microsoft paying SCO to fight with Novell about UNIX and source code in Linux, as an underhand way to try to stop the success of Linux challenging the monopoly of Windows. (Happily, MS has moved on a fair bit since those days.) It's no wonder that the great majority of the Linux community, and Linux distributors, have wanted nothing to do with "official" UNIX. > and maybe they are not willing to put money > into it. Linux works fine just the way it is, > regardless of the "certified UNIX" status. Exactly. > asked whether Linux is a "real UNIX", he replied > that for all sensible definitions, yes, it is. > Or something like that. Yes. The reality, of course, is that such definitions are made by lawyers for corporations with an aim for economic gain or power and control (for future economic gain). They are not "sensible", from technical viewpoints or from the viewpoint of being helpful to end-users. There's nothing wrong with trying to have standards and improving compatibility across systems. The challenge is who defines the standards - volunteer or independent groups can easily run out of money or energy, while company-controlled groups can be misused and biased. > Unix and Linux as "the continuation of ideas that were > started by Ken and me and many others, many years ago" > In any case, all that is pretty much off-topic. But interesting - at least for some of us. > The OP is making a fool of himself. He should just > shut up and go to comp.unix.programmer. Yes. Regardless of any official meaning of "UNIX", Ritchie's definition is the realistic and practical one. c.u.p. covers "unix-like" systems as much as "true UNIX" systems. |
| scott@slp53.sl.home (Scott Lurndal): Jul 05 01:56PM >distributions certified as UNIX 03 compliant." >I have no idea what "03" means but I am pretty >damn sure it does not stand for "2003". That's exactly what it stands for. |
| scott@slp53.sl.home (Scott Lurndal): Jul 05 01:58PM >> kalevi@kolttonen.fi (Kalevi Kolttonen) writes: >How can a 20 year old specification still be >valid in a field that develops very rapidly? It's still being developed, and there are newer versions. https://www.opengroup.org/austin/ |
| scott@slp53.sl.home (Scott Lurndal): Jul 05 02:00PM >was the case for SunOS, AIX, and so on. I could be wrong - or it could >also have been changed. Ultimately, "UNIX" means what the owners of >that trademark decide it means, and the owners have changed over time. The trademark was transferred to X/Open (now the Open Group) two decades ago to be applied after certification against the X/Open specifications (subsequently merged with POSIX). |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 05 11:21AM -0700 On 7/5/2023 12:50 AM, David Brown wrote: > bit since those days.) It's no wonder that the great majority of the > Linux community, and Linux distributors, have wanted nothing to do with > "official" UNIX. [...] Fwiw, I think there was a big legal battle over RCU (Read Copy Update) with IBM and SCO. I need to look it up again. IIrc, my friend Joe Seigh had to testify. |
| kalevi@kolttonen.fi (Kalevi Kolttonen): Jul 05 07:31PM > bit since those days.) It's no wonder that the great majority of the > Linux community, and Linux distributors, have wanted nothing to do with > "official" UNIX. I am too lazy to look up the reference, but I remember clearly what Linus Torvalds admitted years ago. He said that the Linux kernel would not have happened if BSD for i386 had been available. I cannot recall the details, but BSD for PCs was also in some kind of legal trouble. br, KK |
| scott@slp53.sl.home (Scott Lurndal): Jul 05 08:24PM >Fwiw, I think there was a big legal battle over RCU (Read Copy Update) >with IBM and SCO. I need to look it up again. IIrc, my friend Joe Seigh >had to testify. Everything you ever wanted to know about the SCO (Caldera) suit. http://www.groklaw.net/ |
| legalize+jeeves@mail.xmission.com (Richard): Jul 04 11:49PM [Please do not mail me a copy of your followup] "Alf P. Steinbach" <alf.p.steinbach@gmail.com> spake the secret code >I was inspired by Paul N's question about restructuring some Windows >code "to make it look neater", and started coding up some basics. Meh. Just use WinLamb. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment