Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

In the global routing table, or any routing table, for that matter, is a /64 the longest prefix that you can advertise?

[niemand]

For the most part /48s are as long as they'll go. Remember here prefix length is referring to the subnet mask. The more bits in the mask the fewer IP addresses the block accounts for, so shorter prefix = more IP addresses.

192.168.1.0/24 = 24 bit subnet mask = 11111111111111111111111100000000 = 24 bit significant prefix.

Network address formed from the IP address AND the mask = 1100000.10101000.00000001.00000000 AND 11111111.11111111.11111111.00000000 = 1100000.10101000.00000001.0000000.

Network broadcast = IP address XOR (NOT mask) = 11000000.10101000.00000001.11111111 - mask becomes 0.0.0.255 so any 1s in the main IP address remain 1s, 0s remain 0s, until you get to the mask.

10.0.0.0/8 = 8 bit subnet mask = 111111110000000000000000 = 8 bit prefix

[Weaver]

I was just wondering if any systems could not be bothered handling the >64 case where you have to deal with an address that can’t be handled with 64-bit arithmetic. Now C, C++ and D compilers can handle 64bit, but not 128-bit yet, although D has reserved words for 128 bits and nothing else all ready for a bout of future enthusiasm from compiler writers, while GCC has something special of its own though all ready to go iirc : __m128i .

[niemand]

You can do this stuff using, for example, SIMD x86 extensions or vector processing units. No need to handle the entire address as a single octoword, can split into a couple of quadwords or 4 double words and do the bitwise operations work with those.

As it is all bitwise operations no need to hold the entire 128 bits and work on them as a single entity.

>64 bit arithmetic isn't a problem given SIMD and vector processing. 

[Weaver]

I have done the SIMD approach but you have to handle the carries if you’re handling octawords. I’m an old asm programmer by trade. I’m thinking of writing a zero overhead inlined D library for 128-bit integer arithmetic. The x86-64 can deal with ‘dqwords’ already as far as loads/stores go. The choice as to whether to use SIMD instructions more or not depends in part on whether You would like to make use of the SIMD registers simply to get benefit from the additional registers and reduce register pressure. I think I’d like to mix the instruction types as that way can get largest possible register pressure reduction strategy from exploiting both kinds of registers side by side if possible. D can handle SIMD without needing to go to asm but if you’re desperate, superb inlined asm support is available using GCC GDC and LLVM LDC compilers.

[niemand]

In the case of the 'big boys' work would be done by ASICs / FPGAs for the most part so not really an issue.

x64 devices you can find open source routing code online. Maybe have a look at how those folks are handling things - the Linux kernel for instance will have libraries for this.

The hybrid SIMD / x64 instruction approach has the most going for it. Obviously the wider you can spread the instructions across the various execute pipelines available the fewer bottlenecks there will be waiting for resources that are already occupied by previously decoded instructions, the deeper into the pipeline you can go without resource contention and the better use can be made of the various optimisations made by the CPU vendors.

[Weaver]

@CarlT - nice to talk to someone who enjoys low-level stuff too. Such was my job as a developer for about 13 years, including four years of 100% asm and the rest was C.

[niemand]

It's not even about enjoying it. Some of my background is information security and my day job is network functions running over x86-64 hardware both bare metal and within VMs. With the lower level exploits found alongside network functionality being taken away from the kernel and run within user space where optimizations to the data plane can be made rather than relying on that kernel it's a part of the job.

Knowing what's going on under the hood makes me a better engineer. That I like taking programs apart by reverse engineering them is a bonus.

[Weaver]

I started out as a games programmer, games in Z80 asm. Then switched to working on a new machine and a programming language interpreter both in Hitachi 6301 asm, then work on graphics for another new machine in 8086 asm then all C as compilers were by then good enough to do a good job. In the 1990s I worked for years on the development of transport and lower layer protocols for various RF WANs, building a network-independent library that could hide the difference between the different available network types.

[niemand]

There are many excellent YouTube videos that can introduce people to the concepts.

Computerphile is a superb channel for those starting out.

It should always be remembered that whatever your computer produces, the graphics, the computation, whatever, it's an overgrown calculator on steroids. It still has to create a stack by modifying base pointers, PUSH things onto the stack, POP them off it, MOV values around, CALL to branches and RET back to the program counter that was saved on the stack when the call was made when they're done.