Re: [c-nsp] Leaked Video or Not (Linux and Cisco for internal Sales folks)
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)
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)
> 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)
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?
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/