<heat>
imagine I have an object that's queued for something. that object has a lock and is on a list that also has a lock. I want to have an object_cancel() that race-free checks if the object is queued, and if so, removes it from the list
<heat>
how do I solve this problem without re-locking and making a mess?
<bslsk05>
redirect -> docs.microsoft.com: Channel9 has joined Microsoft Learn | Microsoft Docs
<rustyy>
but now they are unavailble and there is a redirect to some bs ms learn or some other marketing
<rustyy>
does anybody know how to access that content?
<klys>
have you tried web.archive.org ?
<rustyy>
those are videos
<rustyy>
i don't think web archive can do video
sdfgsdfg has joined #osdev
<zid>
it can if they were just .mp4 embeds or whatever
<zid>
using your browser's built in video plugin
<zid>
everything is all streamed these days though for the most part
<rustyy>
thanks, good to know
wille has joined #osdev
ravan has quit [Ping timeout: 256 seconds]
xenos1984 has quit [Quit: Leaving.]
Matt|home has quit [Quit: Leaving]
sdfgsdfg has quit [Quit: ZzzZ]
<geist>
aww crap, just discovered the qemu e1000 driver doesn't do MSI at all
<geist>
you need e1000e
<geist>
i think
<kazinsal>
yeah
<kazinsal>
the e1000 emulates a PRO/1000MT iirc
<kazinsal>
MSI was introduced on the 82576
<geist>
82540 it seems
<kazinsal>
e1000e in qemu and vmware parlance
<geist>
is what it seems to be using
<geist>
the intel docs for the 82540 say that MSI is supported, but guess qemu decided not to implement
<kazinsal>
hmm, yeah, seeing that in the docs as well
<kazinsal>
VMware doesn't implement MSI on the 8254x either
<geist>
looks lke it's valid to not export MSI though: there's talk in the doc for the EEPROM bit to enable/disable it
<geist>
so it's valid for it to not appear to have MSI enabled
<kazinsal>
what device ID is qemu implementing?
<geist>
8086:100e
<kazinsal>
gotcha, I've got that written down as 82540EM
<geist>
it supports a few other variants though
<geist>
82544gc and 82545em
<kazinsal>
my doc says that the 82547GI/EI and the 82541 are the only ones that don't support MSI
<geist>
seems to only just do it to make OSes happy though, doesn't really change the functionality of what it implements
<kazinsal>
same set of three that virtualbox implements
<kazinsal>
unsurprising, half of their device emulation seems to be ripped off from qemu
<kazinsal>
ah, MSI is optional on PCIe 2.2 and 2.3 but required on PCI-X
<kazinsal>
er, PCI
<kazinsal>
not PCIe
<j`ey>
talking of VirtualBox.. I booted a gentoo ISO, and it deteced that it was running under KVM
<kazinsal>
qemu et al implement the e1000 as a PCI 2.3 device
<j`ey>
.. but I'm on macOS??
<kazinsal>
virtualbox does partial paravirtualization support to make certain OSes happy
<geist>
yah i actually went through at some point and tried all the options and saw what it changed
<geist>
and sure enough it changed what it exported in cpuid 0x4000.0000 space
<geist>
i give vbox credit there for at least trying to play along with different guests
xenos1984 has joined #osdev
<geist>
yah i really dont see a way to force msi support on for e1000
<geist>
ie, no `-device e1000,msi=on`, etc
<geist>
but e1000e has by default a MSI and MSI-X capability
sdfgsdfg has joined #osdev
<zid>
okay so time to switch to e1000e I guess, are they similar enough I can reuse the driver?
<klange>
they are backwards compatible across several generations
<klange>
Modulo some quirks, the same driver can work with all of them, but each generation added a lot of features, so (eg) Linux ended up with several different drivers to ease development (e1000, e1000e, igb, and now there's "igc", which is a stupid name)
xenos1984 has quit [Quit: Leaving.]
<geist>
looks to me the primary difference is the e1000es support more than one RX and TX ring
<geist>
and thus MSI-X to let you register multiple irqs, etc
<zid>
fancy, is there a point to that though?
<zid>
maybe with queue filtering
<geist>
performance. you can spread the load across a bunch of cores
<zid>
oh right, less lock contention for updating the status bit heh
<geist>
but it's smarter than that because it tries to put packets from similiar sockets and whatnot
<geist>
so i think what it does is it hashes a bunch of the TCP/IP addresses and ports such that packets for a single socket end up being on the same queue
<geist>
i think
<zid>
that's handy, and more or less what I was thinking re queue filtering
<zid>
like if you had multiple IPs assigned
<geist>
i remember this being a problem with my firewall box and gigabit fiber and VLANs + PPPoE. the stack of vlan + pppoe would defeat the hashing which forced the e1000e hardware to put everything on queue 0
<geist>
which actually would saturate the atom chip in the router
<geist>
and thus would max out around 800mbits
<zid>
still pretty good for an atom
<geist>
yah i wasn't really complaining too much,but cpu 0 would basically hit 100%
<zid>
try it with PURE STREAMS BASED NETWORKING
<geist>
but yeah curious if it makes sense to try to have a single driver that is fully backwards compatible
<geist>
anyway in the interim i got the irq working with the legacy number (IRQ 10 in this case). need to add interrupt stacking support and will survive with that for now
<zid>
Mine's on 10 too are you spying on me
<klange>
I'm going to spend the holidays on xhci...
<geist>
yah i was really looking forward to wiring up MSI today
<geist>
but will have to switch to e1000e or probably AHCI next to do it
<geist>
i actually have a few physical i210 cards so i should actually get it working with that anyway
<geist>
and my ryzen machine has a..... i211 in it it seems
<geist>
also fwiw linux seems to use 5 interrupts for i211. probably 4 queues + 1 extra maybe?
<geist>
anyway, i think the way the registers are laid out you canstill ignore the multiple queues per rx/tx
<klange>
The fifth is probably for link status change?
<geist>
yah that'd be my guess
<klange>
My T410 has a 82577LM which I think is old enough to be relegated to the e1000e driver. Its really down to feature checklists. It does have multiple tx/rx queues, though...
ZombieChicken has quit [Quit: WeeChat 3.3]
zaquest has joined #osdev
Matt|home has joined #osdev
ElectronApps has quit [Remote host closed the connection]
ElectronApps has joined #osdev
<sahibatko>
Oh, what a backstab from Windows host again - running qemu with -accel whpx makes some weird behavior, it runs 64bit code, but i.a. info registers shows info as if in 32bit mode. Without whpx, everything is normal.
ElectronApps has quit [Remote host closed the connection]
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
ElectronApps has joined #osdev
dormito has quit [Quit: WeeChat 3.3]
ElectronApps has quit [Remote host closed the connection]
ElectronApps has joined #osdev
ElectronApps has quit [Remote host closed the connection]
ElectronApps has joined #osdev
Burgundy has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
GeDaMo has joined #osdev
dormito has joined #osdev
xenos1984 has joined #osdev
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
sdfgsdfg has joined #osdev
gog has quit [Quit: byee]
someonejv has joined #osdev
heat has joined #osdev
xenos1984 has quit [Quit: Leaving.]
<heat>
how does displayport over usb c work?
<heat>
this isn't connected to the gpu...
<heat>
ah wait these are special ports
someonejv has quit [Read error: Connection reset by peer]
<heat>
i wanted to get 1080p 160hz from this monitor using my laptop
<heat>
it turns out my GPU can't do hdmi 2.0 and this has no displayport
<heat>
but do not fear, it has a VGA port!
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
someonejv has joined #osdev
dennis95 has joined #osdev
ahalaney has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
<hbag>
oh god i missed the last lab and now i have no idea how to print a string in MIPS
<GeDaMo>
If you're using a MIPS emulator, they usually implement some fake syscalls
<hbag>
aaaaaaand now ive hit a wall trying to figure out how to multiply an input by a power of 2
<hbag>
i mean i know HOW but im not really sure how to fuckinnn
<GeDaMo>
2*x = x+x
gog has joined #osdev
<hbag>
...in MIPS
<GeDaMo>
Does MIPS not have an add instruction?
<hbag>
oh right i get what youre saying
<GeDaMo>
Left shifting by 1 would have the same result
<hbag>
yeah thats what i was gonna do
<hbag>
but im yet to figure out how to hard-code a register to store a value
<hbag>
and the instruction to left-shift only takes registers, not values
<hbag>
as does the instruction to multiply
<GeDaMo>
The version I'm looking at only takes an immediate shift value
<hbag>
wait i think i got it
<hbag>
no nevermind
<bauen1>
surely that can't be that hard ... but then there are really weird computer architectures that make you jump through multiple hoops backwards while balancing a pen on your nose, just to access memory at an absolute address
<GeDaMo>
By the way, there's an ##asm channel
<hbag>
oh lmao
<GeDaMo>
Assembly language is on-topic for osdev but it tends to be more ... esoteric :P
* gog
wanders in esoterically
sdfgsdfg has quit [Read error: Connection reset by peer]
sdfgsdfg has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
heat has quit [Remote host closed the connection]
bauen1 has quit [Read error: Connection reset by peer]
srjek has joined #osdev
ElectronApps has quit [Remote host closed the connection]
<hbag>
now that ive had this 1 single lab writing assembly i want to try writing a bootloader again
bauen1 has joined #osdev
xing_song has joined #osdev
bauen1 has quit [Ping timeout: 240 seconds]
river has quit [Ping timeout: 240 seconds]
<gog>
omg i got relocations working
<gog>
;aoigrhg;asjfd
<j`ey>
gog: yay
<GeDaMo>
Did you relocate the keys on your keyboard? :|
<gog>
yes
<Matt|home>
honestly surprised the ink on my keyboard is holding up as well as it is.. my num lock LED is basically non existant (still can see it tho), and a and s are completely gone.. everything else is visible
<kingoffrance>
eh, my laptops seem to have little "braille" indents for f, j, and num pad. what more do you need?
<GeDaMo>
My keyboard lettering is still as good as when I got it ... in 1992 :P
<kingoffrance>
*outdents
xenos1984 has quit [Quit: Leaving.]
* vdamewood
relocates a fishy to gog.
pretty_dumm_guy has joined #osdev
* gog
chomps fishy
vin has joined #osdev
<GeDaMo>
# You shall have a fishy, on a little dishy, when the boat comes in #
<vin>
Off topic: So I have a set of models that generates these numbers and each number correspond to a variant of the model. A baseline is the simpler model that I would like to compare others with. If I have a bunch of numbers that must be assigned points based on their performance relative to the baseline, how do I go about it?
<vin>
Static threshold, say 2x (full points) 1.5x 0. 0.5x 0.25x (some points) than baseline won't work since there can be cases where no number is greater than 2x.
<vin>
points represent how good the model is, even if model does 2x worse than baseline, I still want to give it some points but some constant.
<vin>
One scheme I am currently considering is to find the max and min speed up factor (with respect to the baseline) and then classify them into 4 buckets. However, this ends up comparing models with eath other (I don't want relative performance between models).
<vin>
Any thoughts?
<GeDaMo>
maybe ask ##statistics or ##math ?
<vin>
Thanks GeDaMo let me try
mahmutov has joined #osdev
PyR3X_ is now known as PyR3X
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #osdev
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
<Matt|home>
pfffffft........ so.. i want to be able to read executable files into memory. is it a good idea to hardcode size limits, especially for 32-bit, and if so what would acceptable limits be
<gog>
the size limit for any image would be the size limit of userspace ultimately
<Matt|home>
.. yeah but users are really stupid..
<gog>
well if you have a 50/50 split for address space it'd be 2GiB
<gog>
more or less
<gog>
and the kernel is enforcing access
<Matt|home>
fair enough
<Matt|home>
i'll take that number
<gog>
so if the system tries to load too much it'll just crash
<gog>
the process, not the system
<gog>
like the basic steps would be 1) open and validate the image, process loader mmap()s segments, sets BRK etc then if you're doing lazy allocation the kernel handles the details of what parts of the file are mapped into memory
<Matt|home>
i feel like in 10 years this is gonna be laughed at.. but if you have an executable greater than 2 GB you clearly are not good at space management
<gog>
it's easily possible to need data in excess of 2GB however
<gog>
like every game made since 2003
<GeDaMo>
Windows 32-bit used 2+2GB user/kernel split, Linux used 3+1
<gog>
windows has a /3gb boot option or something iirc
<gog>
but it severely limits kernel object space
<gog>
and windows likes its kernel objects
<Matt|home>
realistically i _can_ go back and change the size limits in future updates though.. like from a purely theoretical perspective if i were to release this commercially (lol) it wouldn't be a big issue
kingoffrance has quit [Ping timeout: 250 seconds]
<Matt|home>
aight. ty
xenos1984 has joined #osdev
kingoffrance has joined #osdev
<kingoffrance>
"i feel like in 10 years this is gonna be laughed at.. but if you have an executable greater than 2 GB you clearly are not good at space management" yeah but then they'll hit some other limit, and you can laugh at them for not doing things modularly
<kingoffrance>
there will be limits, no matter what
dennis95 has quit [Quit: Leaving]
rustyy has quit [Quit: leaving]
rustyy has joined #osdev
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
<geist>
well in 10 years the question will be 'where did you find 32bit hardware to load on?'
<geist>
but that being said even modern 64bit arches still have 2GB/4GB style limits, usually in the form if quick PC relative addressing
<geist>
so a limit there that will be hit is 4GB text segments
<zid>
and maybe requiring some LO MEM
<zid>
enough to get things initialized for long mode
<zid>
so no disabling the ram below 1MB or just having it as a mirror and moving all the ram wherever you want on the bus
amazigh has quit [Quit: regular distro update]
srjek has quit [Ping timeout: 240 seconds]
* kingoffrance
writes script that generates 11M script
<kingoffrance>
i wonder what the sh limit is :)
<kingoffrance>
the first script is 350 lines lol
_xor has quit [Ping timeout: 268 seconds]
CryptoDavid has joined #osdev
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
nj0rd has quit [Quit: WeeChat 3.3]
Oli has joined #osdev
dude12312414 has joined #osdev
nj0rd has joined #osdev
rustyy has quit [Quit: leaving]
<geist>
dunno, i remember finding out interestingly that sh doesn't read the file into memory at once like you'd think
<geist>
that's the general reason why a lot of scripts do the large function and then call the function at the bottom of the sh file
<blockhead>
line at a time i'd assumed?
<geist>
presumably it forces sh to read it entirely in, parse it, then go back and run what it has parsed
<geist>
blockhead: yeah
* blockhead
remembers editing the last line f a script while it was excuting and when it got to the last line, it read my edit
<blockhead>
was a while ago, that could have changed?
<geist>
even more interesting if you modify a sh script while running it it'll get upset, almost lik eit closes and reopens the file for every line
<geist>
i dunno precisely why that's the case, but it seems to be defacto behavior that maybe all sh clones have adopted?
<geist>
you'd think even if it opened the file once and held the fd open it'd see the old deleted file if your editor did the whole new file rename dance
<geist>
which most do
rustyy has joined #osdev
<zid>
I wonder if that's a constraint for incredibly low mem systems for running very large scripts
<geist>
that's my guess
<geist>
i can imagine it being some defacto thing because old computers
<geist>
as in in the 70s or 80s thats just how you did it
<geist>
i *am* surprised though that sh doesn't just hold the fd open though and keep reading from it
<geist>
that doesn't seem to have any advantage except some sort of specific reason, like it's actually desirable that it sees new changes to the file
<bslsk05>
en.wikipedia.org: Sticky bit - Wikipedia
<geist>
i guess the #! logic would have to honor the sticky bit and start the interpreter with it
<kingoffrance>
yeah, i mean you could sticky your shell ... dumb question time, can you make your shell a shell script?
<Arsen>
yes
<geist>
dont see why it'd be any different than writing a shell in python or whatnot
<geist>
as a programming language the only difference i see with shells is they have a focus on having a more powerful immediate mode
GeDaMo has quit [Remote host closed the connection]
_xor has joined #osdev
dormito has quit [Quit: WeeChat 3.3]
amazigh has joined #osdev
<dh`>
traditionally script interpreters can't themselves be scripts
<dh`>
(that is, the argv substitution is only performed once)
biblio has joined #osdev
sdfgsdfg has joined #osdev
srjek has joined #osdev
ahalaney has quit [Remote host closed the connection]
Oli has quit [Quit: leaving]
dormito has joined #osdev
CaCode has joined #osdev
wootehfoot has joined #osdev
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
<geist>
erg this is annoying: already found one subtle difference between 8254x (e1000) and 82574 (e1000e): the EERD registers DONE bit is in a different spot
<geist>
so when reading from the eeprom you have to spin on a different bit to make sure it completed
wootehfoot has quit [Read error: Connection reset by peer]
srjek has quit [Ping timeout: 240 seconds]
<zid>
You're supposed to bother doing that?
<zid>
I read precisely 6 bytes from the eeprom and just treat it like regular mmio
<kazinsal>
geist: oh ho, that's good to know
<geist>
zid: yeah but there's a 'DONE' bit you're supposed to spin on
<geist>
looks like the EERD register changed post 82540, the format changed
<kazinsal>
zid: on physical hardware it matters more
<geist>
yah absolutely
<geist>
and yeah it's all about reading the MAC address out of the eeprom
<kazinsal>
on virtual hardware you're going to be VMEXITed until the byte is written back to your code
<zid>
geist: When are you supposed to wait and forwhy?
<geist>
because the eeprom may be clocked much slower than the chip
<zid>
before you read each byte?
<geist>
after. you put the address in the EERD and then spin until the DONE bit is set and your data is ready
<geist>
that's extremely common
<geist>
and yes in VMs it'll appear instantly
<zid>
I guess you'd need to know precisely how all the buffering and stuff works to deal with the different baud rates etc on pci-e to have an intuition for this
<geist>
no, i'm literally reading the manual and it says precisely to do this
<zid>
I figured I could just do the read, pci-e controller turns it into a packet
<zid>
then my read completes when the reply packet comes
<geist>
very common to have DONE bits for various operations like RST or whatnot
<zid>
but if the cpu/pci-e/etc can't organize that happening it obviously makes sense
<geist>
no no, yu're thinking too hard. this is simply that the e1000 EEPROM access mechanism has a DONE bit that you're supposed to spin on
<zid>
I get that
<zid>
I'm not telling you you're lying lol
<zid>
I said what *my assumption* was
<geist>
yah it'd be lame if PCI stalled the cpu waiting for it
<zid>
And why I didn't code in a spin
<geist>
i dont think it's allowed to do that
<zid>
I figured that'd just come down to UC/WC/etc PAT/mtrr/etc cache bits
<geist>
if the eeprom is clocked at say 10Mhz then accessing a byte out of it will take an eternity for the cpu
<zid>
whether it was allowed to do that
<zid>
and my pci-e stuff is all marked strong UC
<geist>
maybe it can, but that would be highly lame if it literally stalled the bus waiting for some internal access
<zid>
the cpu is obviously designed to allow for memory accesses to be either fast or slow, because of cache
<zid>
so I figured it'd just see it as "very wonky l4 over pci-e" maybe :P
<zid>
It'd speculate around it etc, but my code still needs to *see* the result before it can continue, so whether I am spinning on a status bit or just stalled waiting for the read didn't seem relevent
* geist
shrugs
<geist>
anyway, looks like interrupt masking and acking works a bit different too
<geist>
so debating if it's worth trying to build an uber driver or not
<geist>
probably worth it as long as i stick to simple stuff
<geist>
and thus far maybe a `bool e1000e` to test at critical spots
<zid>
compile time or runtime? :)
<geist>
runtime
<geist>
i mean i could i guess templatize it, but then i'd get double the code
<zid>
or just #define and compile it two ways
<zid>
e1000.o: e1000.c\n\t gcc -c -DE1000 ..
<zid>
e1000e.o: e1000.c\n\t gcc -c -DE1000E ..
<zid>
My thinking being that it's unlikely any machine ever has *both* drivers loaded, which is the case you'd want to avoid
<geist>
sure. but that'd be the same thing: double the code with all of the annoyance of having if statements or #if or whatnot
<kazinsal>
I've seen machines with both
<zid>
I'm not saying it can't happen, it obviously can, I just think it's unlikely
<geist>
but i'm starting to see why qemu and linux both have separate drivers for e1000 and e1000e
<zid>
So in the majority case you get a much smaller driver loaded into memory
<geist>
oh sure if it's a loadable module indeed
<zid>
that's a point, you need loadable module support
<kazinsal>
iirc openbsd has one if_em.c that handles the commonalities and calls out to functions in if_em_hw.c for specific hardware revision stuff
<zid>
if you want to support both without duplicating
<geist>
anyway, it's more like the e1000e stuff is sufficiently more complex that it makes sense to not burden it with a bunch of legacy stuff
biblio has quit [Quit: Leaving]
<geist>
but i think that only matters if you're actually using the new features
<zid>
I'd probably just make an intel-nonsense-common.c and they can both link against that, sharing what can be shared
<geist>
so for now i think it makes sense that the amount of little switches here and there are okay
<geist>
up until it starts to get onerous
<zid>
if e1000e drifts and it stops needing anything, you could recombine common.c and e1000.c
<zid>
depends how full-ass you're going to do the e1000e support
<geist>
FWIW i'm also using C++ for this driver, so i have a few more tools in the shed
<geist>
like just templatizing the whole object based on which one it's compiling for
<zid>
in my case I don't need multiple queues and vlan supports and blah blah cus there's no userspace syscall to deal with it so who cares
<geist>
and then you end up with micro optimized stuff with all the if statements folded away
<zid>
templates are just fancy defines
<geist>
right
<zid>
I think this in general is one of the 'hard' parts of osdev, deciding how assed your *final* implementation will be
<geist>
haha yeah
<zid>
As what you would do for the first version differs depending
<geist>
i do generally tell people that ethernet drivers are a good first complex driver though, specifically because there's a fairly tangible 'finished' state
<geist>
as in does it work, does it move packets efficiently enough, done.
<zid>
"I'm going to support like a few e1000 models and the easy bits of e1000e" is different to "every single model of e1000 and every feature on an e1000e"
<geist>
totes
<zid>
The former I'd literally just write an e1000.c the latter I'd have three files, blah blah
<zid>
saves a couple refactors if you get your guess right on how it will eventually end up
<geist>
i did read a bit about how the MSI-x and multiple vectors work on the e1000e last night. it's pretty sophsticated
<geist>
basically you have up to 5 vectors and then there's some control registers that let you map interrupt reasons to vectors
<geist>
so it's not particularly hard coded what goes to what
<geist>
then you can also configure per interrupt reason as to whether or not it auto clears upon sending the IRQ or not. so you can configure, for example, RX ring 0 to go to MSI vector 1 and then not requiring any interrupt status register be read in the handler
<geist>
because it's implicit
<geist>
oh and the 'up to 5 vectors' is for the i210. something like an i350 is basically the same but it supports more vectors (up to 24 i think) and 8 rx and 8 tx rings
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<zid>
fanshy
<geist>
also s/i210/i211
<geist>
i211 is a cheaper alternative, basically the lowest end of that family. specifically it only supports 5 MSI-xs and 2rx 2tx
<geist>
whereas a i210 is i think 10 4rx 4tx
<geist>
and i350 is 24 8rx 8tx
sdfgsdfg has quit [Quit: ZzzZ]
<kazinsal>
and then i7xx is a whole new chip iirc
<geist>
is that 10gbe?
<kazinsal>
10/25/40
<geist>
wondering if they made some sort of fundamental design shift for 10gbe. i wonder i the classic ring strategy scales up to that
<kazinsal>
if the product name starts with X, it's 10, XXV, 25, XL, 40
<geist>
did they made a i740? long live the i740
<kazinsal>
Intel 740iL
<geist>
haha
<zid>
It's kinda weird that intel just makes very good ethernet transceivers
<kazinsal>
there's a lot of little things that they just do really well and it's not stuff most people expect to be in their wheelhouse
<geist>
yah i assume that basically realtek and intel have the entire ethernet chipset business carved up between them
<geist>
and in server space i assume it's either custom in-house or intel
<kazinsal>
them and broadcom yeah
<geist>
marvell has a tiny slice with the attansic stuff i think
<geist>
all of the cheap 10gbes i've seen are that
<geist>
but i doubt thats much of a blip in the overall market
<zid>
intel started as a neat random chip company, but most things got shed off and they focued on the 8086 improvements... that ethernet of all things is the thing that survived seems just kinda random
<geist>
ah not attansic, Aquantia
<geist>
AQN-107. i have a pair of those in my nas box + home server to set up a 10gbe link
<geist>
probalby not the fanciest 10gbe but seems to be able to push 800MB/sec or so without much trouble
<geist>
and the cards aren't too bad, about $100
<kazinsal>
oh that reminds me, there's a new intel NIC chipset
<kazinsal>
E810
<kazinsal>
up to dual 100GbE per controller
<kazinsal>
PCIe 4.0x16
<geist>
yah, was gonna say need a lot of pcie for that
<geist>
that was a thing i hadn't planned on when i got the 10gbe nic: you need an x4 for it
<geist>
i had to move some pci cards around for that