Re: [c-nsp] Leaked Video or Not (Linux and Cisco for internal Sales folks)

2018-06-29 Thread James Bensley
On 29 June 2018 at 13:55, Gert Doering  wrote:
> Hi,
>
> On Fri, Jun 29, 2018 at 01:49:46PM +0100, adamv0...@netconsultings.com wrote:
>> Just wondering what's the latest on the GPU for packet forwarding front (or 
>> is that deemed legacy now)?
>
> Last I've heard is that pixel shaders do not map really nicely to the
> work needed for packet forwarding - so it works, but the performance gain
> is not what you'd expect to see.

Which is to be expected right? Typical GPU instruction sets and ALUs
are great for floating point operations which we don't need for packet
processing. Packets typically need low complexity tasks performed at
high rates. Various high end DC switches like Nexus boxes use GDDR5
RAM just as a graphics card would but the processing is done by an
ASIC, which makes sense to me, that is not the place for general
purpose x86 compute chips. This is a specific task.

Cheers,
James.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Re: [c-nsp] Leaked Video or Not (Linux and Cisco for internal Sales folks)

2018-06-29 Thread Gert Doering
Hi,

On Fri, Jun 29, 2018 at 01:49:46PM +0100, adamv0...@netconsultings.com wrote:
> Just wondering what's the latest on the GPU for packet forwarding front (or 
> is that deemed legacy now)?

Last I've heard is that pixel shaders do not map really nicely to the
work needed for packet forwarding - so it works, but the performance gain
is not what you'd expect to see.

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Re: [c-nsp] Leaked Video or Not (Linux and Cisco for internal Sales folks)

2018-06-29 Thread adamv0025
> From: Tails Pipes [mailto:tailsnpi...@gmail.com]
> Sent: Thursday, June 28, 2018 5:29 PM
> 
> No, things changed there as well. Lookup merchant sillicon, and revise this
> post every 6 months. 
Nah 
> have you heard of Barefoot networks? 
Yes I have heard of barefoot, but have you heard of barefoot queuing 
architecture or pre-classifier granularity and queuing strategy or packet size 
based pps performance graph, well yeah neither did I.

> The days of
> ASICs from Cisco are gone and we are glad, we tested the P4 DSL (cisco never
> got that right with mantel) on Nexus and its wonderful.
> 
> The asics you speak of are no longer important or valuable because people
> realized that in many networking planets and galaxies, the asic is reflects 
> the
> network design, they are related, and specifically for the data center, the 
> clos
> fabric design won, and that does not require fancy asics.
Well there are use cases for fancy asics and use cases for simple asics.
 

> I guess your knowledge is out dated a bit. Cisco itself is using those 
> merchant
> sillicon ASICs happily. 
Yup and those are dirt cheap compared to their home grown asics , this is 
because for a given pps rate they have lot less smarts.
 
> (lookup Chuck's comments on nexus9000, best selling
> cisco switch ever)...guess it is a good switch, because bright box pushed 
> cisco
> to do that, and if any one on this list can disagree with me here, i'm up to 
> that
> challenge.
> 
> What i have discovered recently is that things happen in following way.
> 
> Your boss or his boss picks a work culture (no one gets fired for buying
> IBM/Cisco), that culture (buying the shiny suits) impacts how you do work, it
> makes you select vendors (the ones that sends me to vegas every year) and
> not the right network design, you select cisco and you are stuck there for 
> life,
> because once they tell you how things should work (aka : certificates), things
> are worse, now every time you make a new network purchase (afraid of new
> CLI ), you will not be able to look the other way because you just dont know
> any thing else (and loosing your certificate value).
> 
Well I guess that could be a story of some of the smaller shops that can't 
afford investing in R and thus rely on well-trodden paths, but certainly not 
my problem.
 

> I wish the culture would change to, no one got fired for buying closed but
> didnt get promoted either. change requires boldness.
> 
> https://toolr.io/2018/06/18/stop-abusing-the-word-open/
> 
I understand your passion for open sw and open hw architecture, but routing 
high pps rates on x86 will always be impractical compared to specialized asics.
Yes going x86 certainly makes sense for low pps use cases - a uCPE is a good 
example of such a use case.
And as far as the high pps rate use cases goes, reading other posts in this 
thread, it seems that the current state of the art with regards to any linux OS 
driving any white-box ASICs is not quite ready for primetime yet.  
A viable alternative might be the FPGA NICs -but seems still not financially 
attractive. 
Just wondering what's the latest on the GPU for packet forwarding front (or is 
that deemed legacy now)?


adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Re: [c-nsp] Leaked Video or Not (Linux and Cisco for internal Sales folks)

2018-06-29 Thread Saku Ytti
Hey Gert,

> (Yes, we have templates for both pre-ELS and post-ELS, but having to
> figure out what is new now and how and why port-unrelated things have
> to be changed was an unneccessary waste of lifetime)

Not disagreeing, but on the scale of approving new hardware, writing
new templates isn't that significant OPEX cost. New platform means
learning new limitations of HW, new corner cases, new way to
troubleshoot, new things to monitor, it's inevitably rather huge
chore. Maybe there comes a day when we don't have to be hyper-aware of
the underlaying hardware in networking kit, but that certainly isn't
today, in that future, this would have been relatively much larger
issue.
Perhaps this is more marketing problem than technical, as they are
presenting it as minor upgrade, when in reality everything changed.

It would be still interesting to hear what was the reason. Would the
preELS map poorly to modern switching asics, is postELS more in-line
on how forwarding-plane is actually programmed? Or could they have
trivially supported preELS, but regardless of BRCM noticed their first
attempt at switch CLI has inefficiencies they decided to remedy while
changing everything anyhow.

-- 
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Re: [c-nsp] line con 0 as terminal server on Cat6500?

2018-06-29 Thread Patrick M. Hausen
Hi all,

> Am 19.05.2018 um 18:52 schrieb Lee :
> It's been several years since I've seen a 6500, but I doubt things
> have changed.  There's two boot registers on the 6500 - the switch
> processor and the route processor.  The switch boots up first and then
> hands off to the route processor, so under normal circumstances
>  show boot
> shows the boot variables for the route processor & [maybe not the
> correct syntax]
>  remote command switch show boot
> shows the boot variables for the switch processor.
> 
> So if the SP confreg = 0x0 when the box reboots it stays in rommon
> even if the RP confreg = 0x2102

Thanks for reminding me that this platform acts a bit schizophrenic at times ;-)
And of course you nailed it.

Standby chassis switch processor:
Configuration register is 0x2100 (will be 0x2102 at next reload)

I think it's pretty odd that a controlled reload is required to save the new 
setting.
We did that in a maintenance window and now all 4 registers of our VSS  are
set to 0x2102.

Thanks
Patrick
-- 
punkt.de GmbH   Internet - Dienstleistungen - Beratung
Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100
76133 Karlsruhe i...@punkt.de   http://punkt.de
AG Mannheim 108285  Gf: Juergen Egeling

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/