On Jun 12, 2011, at 4:04 AM, Aragon Gouveia wrote:
> While we're on this subject I thought I'd bring up something that
> MikroTik are doing with some of their Routerboards. Could be a nice to
> have feature on future Soekris boards too!
>
> Their RB450G, RB750G, and some other new boards incorporate dedicated
> switch controllers wired to the onboard ethernet ports. What's great
> about this setup is that port routing can be set in software. Ports can
> be selectively routed to the switch controller for wire speed switching,
> or to the CPU for L3 routing and/or software bridging. The best of both
> worlds!
>
> Wouldn't it be nice to have something like this on our Soekris boards?
>
actually the way that's done is a the atheros system on a chip (ar7130 or 7161
in this case) includes the ethernet switch... this a fairly typical as an
approach to building a wireless ap... the BOM is reduced because you've got
one major chip with all the components on it. on the other hand you get to live
with a 32bit mips 24k running at 160-600mhz and 16-128MB of ram depending on
the board you're talking about so if that is appropriate for your application
great and if not then it isn't.
>
> On 06/12/11 05:43, der Mouse wrote:
>>>> the ports are just ethernet interfaces so all your switching is
>>>> being done in software if that's what you're asking.
>>> Would that mean that a pair of machines transferring at full speed on
>>> eth0 and eth1 would not reduce the available bandwidth for another
>>> pair on eth2 and eth3?
>>
>> Depends on multiple factors.
>>
>> - Ethernet hardware. Sometimes there's a shared piece of hardware that
>> can't handle full-bore I/O on all ports at once - I don't know
>> whether this is true of the 5501 or not.
>>
>> - Bus bandwidth (this is, strictly, a shared piece of hardware such as
>> mentioned above, but it's shared with, typically, a lot more than
>> just the Ethernets). However, when doing a software switch, packet
>> contents must be copied across the bus into main memory, then copied
>> back again on transmission. Depending on the bus(es) involved and
>> how DMA works, this may or may not be a problem.
>>
>> - CPU. The CPU has to look at each packet at least a little (typically
>> just the Ethernet header, but that means servicing a cache miss, and
>> probably some kind of shootdown when the DMA happened too).
>>
>> - Likely other factors I haven't though of.
>>
>> My guess - and it's a total guess - would be that bus bandwidth will be
>> your limiting factor. But I'd have to measure it to be sure. If the
>> other factors are capable enough, the limiting factor will be the
>> network wire speed; this is the best case from your point of view, and
>> for all I know might actually obtain for you.
>>
>>> If not, then how can that be achieved.
>>
>> Dedicated switches typically have custom silicon for the switching
>> fabric. If you want full wire speed on a lot of fast ports at once
>> ("fast" may include 100Mb and almost certainly includes Gb), you won't
>> get it without custom silicon. But if your "full speed" is slow
>> enough, you will be able to do OK with a software switch (but "slow
>> enough" depends on the other factors).
>>
>> One thing you will _not_ get with a software switch is cut-through
>> switching, packet forwarding where transmission starts as soon as
>> enough of the Ethernet header is received to tell where the packet
>> should go (if the destination channel can handle a send at the moment).
>> Each packet must be fully received by the hardware before forwarding
>> decisions are made. This does not, strictly speaking, impair
>> bandwidth, but it does mean forwarding latency will be higher than with
>> custom dedicated silicon switching hardware, which for some kinds of
>> workloads is operationally similar to bandwidth limits.
>>
>> In short, it's a complex question. About all that someone not working
>> closely with your situation can say with confidence is "it depends,
>> you'd have to try it to be sure".
>>
>> /~\ The ASCII Mouse
>> \ / Ribbon Campaign
>> X Against HTML mo...@rodents-montreal.org
>> / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
>> _______________________________________________
>> Soekris-tech mailing list
>> Soekris-tech@lists.soekris.com
>> http://lists.soekris.com/mailman/listinfo/soekris-tech
> _______________________________________________
> Soekris-tech mailing list
> Soekris-tech@lists.soekris.com
> http://lists.soekris.com/mailman/listinfo/soekris-tech
>
_______________________________________________
Soekris-tech mailing list
Soekris-tech@lists.soekris.com
http://lists.soekris.com/mailman/listinfo/soekris-tech
