summaryrefslogtreecommitdiffstats
path: root/sys/dev/e1000/if_igb.c
Commit message (Collapse)AuthorAgeFilesLines
* Merge remote-tracking branch 'origin/stable/10' into develRenato Botelho2016-02-281-143/+69
|\
| * MFC: r295906marius2016-02-261-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix and clean up usage of DMA and TSO segments: - At Intel it is believed that most of their products support "only" 40 DMA segments so lower {EM,IGB}_MAX_SCATTER accordingly. Actually, 40 is more than plenty to handle full size TSO packets so it doesn't make sense to further distinguish between MAC variants that really can do 64 DMA segments. Moreover, capping at 40 DMA segments limits the stack usage of {em,igb}_xmit() that - given the rare use of more than these - previously hardly was justifiable, while still being sufficient to avoid the problems seen with em(4) and EM_MAX_SCATTER set to 32. - In igb(4), pass the actually supported TSO parameters up the stack. Previously, the defaults set in if_attach_internal() were applied, i. e. a maximum of 35 TSO segments, which made supporting more than these in the driver pointless. However, this might explain why no problems were seen with IGB_MAX_SCATTER at 64. - In em(4), take the 5 m_pullup(9) invocations performed by em_xmit() in the TSO case into account when reporting TSO parameters upwards. In the worst case, each of these calls will add another mbuf and, thus, the requirement for an additional DMA segment. So for best performance, it doesn't make sense to advertize a maximum of TSO segments that typically will require defragmentation in em_xmit(). Again, this leaves enough room to handle full size TSO packets. - Drop TSO macros from if_lem.h given that corresponding MACS don't support TSO in the first place. Reviewed by: erj, sbruno, jeffrey.e.pieper_intel.com Approved by: re (gjb)
| * MFC r295323:erj2016-02-251-145/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update em(4) to 7.6.1; update igb(4) to 2.5.3. Major changes: - Add i219/i219(2) hardware support. (Found on Skylake generation and newer chipsets.) - Further to the last Skylake support diff, this one also includes support for the Lewisburg chipset (i219(3)). - Add a workaround to an igb hardware errata. All 1G server products need to have IPv6 extension header parsing turned off. This should be listed in the specification updates for current 1G server products, e.g. for i350 it's errata #37 in this document: http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/ethernet-controller-i350-spec-update.pdf - Avoton (i354) PHY errata workaround added And a bunch of minor fixes, as well as #defines for things that the current em(4)/igb(4) drivers don't implement. MFC r287465: igb(4): Update and fix HW errata - HW errata workaround for IPv6 offload w/ extension headers - Edited start of if_igb.c (Device IDs / #includes) to match ixgbe/ixl Approved by: re (gjb) Sponsored by: Intel Corporation
* | Merge remote-tracking branch 'origin/stable/10' into develRenato Botelho2016-02-011-11/+14
|\ \ | |/
| * Sync the e1000 drivers with what's in head as of r294327, modulo partsmarius2016-01-271-11/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | that don't apply to stable/10 (driver API, if_inc_counter(), RSS changes etc.) and modulo r287465 (which reportedly breaks igb(4)), i. e. assorted fixes and improvements only: o MFC r267385 (partial): - Don't compare bus_dma map pointers for static DMA allocations against NULL to determine if bus_dmamap_unload() or bus_dmamem_free() should be called. Instead, check the associated bus and virtual addresses. - Don't clear static DMA maps to NULL. o MFC r284933: Delete the refernce to VLAN handling being disabled by default. This is no longer the case. [1] o MFC r285639: Add an adapter CORE lock in the DDB hook em_dump_queue to avoid WITNESS panic in em_init_locked() while debugging. o MFC r285879: - Remove unused txd_saved. - Intialize txd_upper, txd_lower and txd_used at declaration. o MFC r286162: Free mbufs when busdma loading fails. o MFC r286829: Add capability to disable CRC stripping as it breaks IPMI/BMC capabilities on certain adatpers. [2] o MFC r286831: [3] - Increase EM_MAX_SCATTER to 64 such that the size of em_xmit():: segs[EM_MAX_SCATTER] doesn't get overrun by things like NFS that can and do shove more than 32 segs when being used with em(4) and TSO4. - Update tso handling code in em_xmit() with update from jhb@ - Set if_hw_tsomax, if_hw_tsomaxsegcount and if_hw_tsomaxsegsize to appropriate values. - Define a TSO workaround "magic" number of 4 that is used to avoid an alignment issue in hardware. - Change a couple of integer values that were used as booleans to actual bool types. - Ensure that em_enable_intr() enables the appropriate mask of interrupts and not just a hardcoded define of values. o MFC r286832: e1000/if_lem.c bump to 1.1.0 o MFC r286833: Bump all copywrite dates to 2015. o MFC r287112: Style/whitespace cleanup in shared/common code. o MFC r293331: - Switch em(4) to the extended RX descriptor format. - Split rxbuffer and txbuffer apart to support the new RX descriptor format structures. Move rxbuffer manipulation to em_setup_rxdesc() to unify the new behavior changes. - Add a RSSKEYLEN macro for help in generating the RSSKEY data structures in the card. - Change em_receive_checksum() to process the new rxdescriptor format status bit. o MFC r293332: Disable the reuse of checksum offload context descriptors in the case of multiple queues in em(4). Document errata in the code. o MFC r293854: Given that em(4), lem(4) and igb(4) hardware doesn't require the alignment guarantees provided by m_defrag(9), use m_collapse(9) instead for performance reasons. While at it, sanitize the statistics softc members, i. e. retire unused ones and add SYSCTL nodes missing for actually used ones. PR: 118693 [1], 161277 [2], 195078 [3], 199174 [3], 200221 [3]
* | Merge remote-tracking branch 'origin/stable/10' into develRenato Botelho2016-01-251-4/+7
|\ \ | |/
| * MFC r290641:tuexen2016-01-171-4/+7
| | | | | | | | | | | | Add support for SCTP checksum offloading for the 82580 controller similar to the 82576 controller. Tested with Intel i340 cards.
* | Merge remote-tracking branch 'origin/stable/10' into develRenato Botelho2016-01-151-2/+13
|\ \ | |/
| * MFC r292670sbruno2016-01-141-2/+13
| | | | | | | | | | | | | | | | Add support for sysctl knobs to live tune the tx packet processing limits in igb and fix a wrap-around bug. Submitted by: Jason (j@nitrology.com) Sponsored by: Limelight Networks
* | Importing pfSense patch iface_iftx_altq_hybrid.diffRenato Botelho2015-08-171-44/+22
|/
* Partial MFC r281838:hiren2015-05-131-2/+19
| | | | | | | | | For igb(4), when we are doing multiqueue, we are all setup to have full 32bit RSS hash from the card. Expose that so others like lagg(4) can use that and avoid hashing the traffic by themselves. Setting hashtype as OPAQUE because FreeBSD 10 doesn't have RSS support. Sponsored by: Limelight Networks
* MFC r275358 r275483 r276982 - Removing M_FLOWID by hps@hiren2015-04-241-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | r275358: Start process of removing the use of the deprecated "M_FLOWID" flag from the FreeBSD network code. The flag is still kept around in the "sys/mbuf.h" header file, but does no longer have any users. Instead the "m_pkthdr.rsstype" field in the mbuf structure is now used to decide the meaning of the "m_pkthdr.flowid" field. To modify the "m_pkthdr.rsstype" field please use the existing "M_HASHTYPE_XXX" macros as defined in the "sys/mbuf.h" header file. This patch introduces new behaviour in the transmit direction. Previously network drivers checked if "M_FLOWID" was set in "m_flags" before using the "m_pkthdr.flowid" field. This check has now now been replaced by checking if "M_HASHTYPE_GET(m)" is different from "M_HASHTYPE_NONE". In the future more hashtypes will be added, for example hashtypes for hardware dedicated flows. "M_HASHTYPE_OPAQUE" indicates that the "m_pkthdr.flowid" value is valid and has no particular type. This change removes the need for an "if" statement in TCP transmit code checking for the presence of a valid flowid value. The "if" statement mentioned above is now a direct variable assignment which is then later checked by the respective network drivers like before. r275483: Remove M_FLOWID from SCTP code. r276982: Remove no longer used "M_FLOWID" flag from mbuf.h and update the netisr manpage. Note: The FreeBSD version has been bumped. Reviewed by: hps, tuexen Sponsored by: Limelight Networks
* MFC 272897:jhb2014-12-161-7/+37
| | | | | | | | | | Various fixes to stats: - Read the counts of received, dropped, and transmitted management packets and add sysctl nodes for them. - Fix the total octets received/transmitted to read all 64 bits of the counters. - Add missing sysctl nodes for rlec, tncrs, fcruc, tor, and tot. - Remove spurious spaces.
* MFC r263710, r273377, r273378, r273423 and r273455:hselasky2014-10-271-8/+8
| | | | | | | - De-vnet hash sizes and hash masks. - Fix multiple issues related to arguments passed to SYSCTL macros. Sponsored by: Mellanox Technologies
* MFC r271784 - Fix the handling of EOP in status descriptors for if_igb(4)adrian2014-10-111-8/+8
| | | | | | | | | | | | | and don't double-free mbufs. Like ixgbe(4) chipsets, EOP is only set on the final descriptor in a chain of descriptors. So, to free the whole list of descriptors, we should free the current slot _and_ the assembled list of descriptors that make up the fragment list. The existing code was setting discard once it saw EOP + an error status; it then freed all the subsequent descriptors until the next EOP. That's totally the wrong order.
* MFC r271645 - Set DROP_EN on each RX queue if transmit flow-control is disabled.adrian2014-10-111-0/+13
| | | | | | | | | | | | | | | | | This allows the NIC to drop frames on the receive queue and not cause the MAC to block on receiving to _any_ queue. Tested: igb0@pci0:5:0:0: class=0x020000 card=0x152115d9 chip=0x15218086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'I350 Gigabit Network Connection' class = network subclass = ethernet Discussed with: Eric Joyner <eric.joyner@intel.com> MFC after: 1 week Sponsored by: Norse Corp, Inc.
* MFC 270063: update of netmap codeluigi2014-08-201-3/+3
| | | | (vtnet and cxgbe not merged yet because we need some other mfc first)
* MFC svn 267065 and 267187luigi2014-06-091-2/+2
| | | | | | | | | | | | | | make sure ifp->if_transmit returns 0 if a buffer is enqueued. This should also be merged to stable/9. After this fix, drivers still known to have this bug are igxbe/ixv and i40e. Drivers using if_transmit are correct, and so are most of the other drivers that reassing if_transmit. Among other things, this bug causes panics when using netmap emulation on top of generic drivers.
* Merge r261169: Fix compilation with IGB_LEGACY_TX defined.glebius2014-03-111-0/+2
| | | | PR: 185909
* MFH: sync the netmap code with the one in HEADluigi2014-02-181-5/+6
| | | | | (enhanced VALE switch, netmap pipes, emulated netmap mode). See details in the log for svn 261909.
* MFC r257541:kib2013-12-171-6/+6
| | | | Fix several issues with the busdma(9) KPI use in the e1000 drivers.
* Update the Intel igb driver to version 2.4.0jfv2013-10-091-435/+498
| | | | | | | | | | | - This version has support for the new Intel Avoton systems, including 2.5Gb support, further it now has IPv6/TSO6 support as well. Shared code has been updated where necessary as well. Thanks to my new assistant Eric Joyner for doing the transmit path changes to bring in the IPv6/TSO6 support. Thanks to Gleb for catching the one bug and change needed in NETMAP. Approved by: re
* Expose system level ixgbe sysctls.hiren2013-10-051-0/+3
| | | | | | | | | | | Device level sysctls are already exposed as dev.ix.<device> Fixing the case where number of queues for igb is auto-tuned and hw.igb.num_queues does not return current/updated value. Reviewed by: jfv Approved by: re (delphij) MFC after: 2 weeks
* Restructure the mbuf pkthdr to make it fit for upcoming capabilities andandre2013-08-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | features. The changes in particular are: o Remove rarely used "header" pointer and replace it with a 64bit protocol/ layer specific union PH_loc for local use. Protocols can flexibly overlay their own 8 to 64 bit fields to store information while the packet is worked on. o Mechanically convert IP reassembly, IGMP/MLD and ATM to use pkthdr.PH_loc instead of pkthdr.header. o Extend csum_flags to 64bits to allow for additional future offload information to be carried (e.g. iSCSI, IPsec offload, and others). o Move the RSS hash type enumerator from abusing m_flags to its own 8bit rsstype field. Adjust accessor macros. o Add cosqos field to store Class of Service / Quality of Service information with the packet. It is not yet supported in any drivers but allows us to get on par with Cisco/Juniper in routing applications (plus MPLS QoS) with a modernized ALTQ. o Add four 8 bit fields l[2-5]hlen to store the relative header offsets from the start of the packet. This is important for various offload capabilities and to relieve the drivers from having to parse the packet and protocol headers to find out location of checksums and other information. Header parsing in drivers is a lot of copy-paste and unhandled corner cases which we want to avoid. o Add another flexible 64bit union to map various additional persistent packet information, like ether_vtag, tso_segsz and csum fields. Depending on the csum_flags settings some fields may have different usage making it very flexible and adaptable to future capabilities. o Restructure the CSUM flags to better signify their outbound (down the stack) and inbound (up the stack) use. The CSUM flags used to be a bit chaotic and rather poorly documented leading to incorrect use in many places. Bring clarity into their use through better naming. Compatibility mappings are provided to preserve the API. The drivers can be corrected one by one and MFC'd without issue. o The size of pkthdr stays the same at 48/56bytes (32/64bit architectures). Sponsored by: The FreeBSD Foundation
* Alter the mq_start routine to do a TRYLOCK and call to the locked routinejfv2013-08-131-1/+7
| | | | | | rather than just queueing. The former code was an attempt at getting UDP performance up, but there have been customer reports of problems with it, so the ixgbe approach seems the best solution for now.
* Update PCI drivers to no longer look at the MEMIO-enabled bit in the PCIscottl2013-08-121-9/+1
| | | | | | | | | | | | | | | | | command register. The lazy BAR allocation code in FreeBSD sometimes disables this bit when it detects a range conflict, and will re-enable it on demand when a driver allocates the BAR. Thus, the bit is no longer a reliable indication of capability, and should not be checked. This results in the elimination of a lot of code from drivers, and also gives the opportunity to simplify a lot of drivers to use a helper API to set the busmaster enable bit. This changes fixes some recent reports of disk controllers and their associated drives/enclosures disappearing during boot. Submitted by: jhb Reviewed by: jfv, marius, achadd, achim MFC after: 1 day
* Improve the MSIX setup code in the drivers, thanks to Marius forjfv2013-08-121-4/+9
| | | | | | | | the changes. Make sure that pci_alloc_msix() does give us the vectors we need and fall back to MSI when it doesn't, also release any that were allocated when insufficient. MFC after: 3 days
* Make the various driver MSIX setup routines fallback to MSI morejfv2013-08-061-13/+15
| | | | | | | gracefully. This change was suggested by Marius Strobl, thank you. PR: kern/181016 MFC after: ASAP
* When the igb driver is static there are cases when early interrupts occur,jfv2013-08-061-0/+4
| | | | | | | resulting in a panic in refresh_mbufs, to prevent this add a check in the interrupt handler for DRV_RUNNING. MFC after: 1 day (critical for 9.2)
* Change the E1000 driver option header handling to match thejfv2013-07-121-2/+3
| | | | | | | | | | ixgbe driver. As it was, when building them as a module INET and INET6 are not defined. In these drivers it does not cause a panic, however it does result in different behavior in the ioctl routine when you are using a module vs static, and I think the behavior should be the same. MFC after: 3 days
* use netmap_rx_irq() / netmap_tx_irq() to handle interrupts inluigi2013-04-301-22/+5
| | | | | | netmap mode, removing the logic from individual drivers. (note: if_lem.c not updated yet due to some other pending modifications)
* Simplify allocate_legacy code, txr pointer was breaking LEGACY compile,jfv2013-04-101-2/+1
| | | | thanks to Nick Rogers for pointing this out.
* Correct the multicast handling in the E1000 drivers as wasjfv2013-04-031-5/+31
| | | | | | done in ixgbe, thanks to Mike Karels for this fix. When exiting promiscuous mode MPE bit was being unconditionally cleared, this should not be done if we are in MAX multicast groups.
* Update man page for igb(4) with a little bit of information aboutsbruno2013-04-031-1/+2
| | | | | | | | | | | hw.igb.num_queues for those so inclined. PR: kern/177384 Submitted by: hiren.panchasara@gmail.com Reviewed by: sbruno@ Approved by: jfv@ Obtained from: Yahoo! Inc. MFC after: 2 weeks
* Change defines in the igb driver to allow an easier selection ofjfv2013-03-291-18/+18
| | | | | | | | the older if_start/non-multiqueue interface from the stack. This is not the default, but can be turned on in the Makefile now regardless of the OS level to allow either testing or use of ALTQ. MFC after: one week
* Refresh on the shared code for the E1000 drivers.jfv2013-02-211-48/+58
| | | | | | | | | | | | | | | | | | | | - bear with me, there are lots of white space changes, I would not do them, but I am a mere consumer of this stuff and if these drivers are to stay in shape they need to be taken. em driver changes: support for the new i217/i218 interfaces igb driver changes: - TX mq start has a quick turnaround to the stack - Link/media handling improvement - When link status changes happen the current flow control state will now be displayed. - A few white space/style changes. lem driver changes: - the shared code uncovered a bogus write to the RLPML register (which does not exist in this hardware) in the vlan code,this is removed.
* This fixes a out-of-order problem with severalrrs2013-02-071-6/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of the newer drivers. The basic problem was that the driver was pulling the mbuf off the drbr ring and then when sending with xmit(), encounting a full transmit ring. Thus the lower layer xmit() function would return an error, and the drivers would then append the data back on to the ring. For TCP this is a horrible scenario sure to bring on a fast-retransmit. The fix is to use drbr_peek() to pull the data pointer but not remove it from the ring. If it fails then we either call the new drbr_putback or drbr_advance method. Advance moves it forward (we do this sometimes when the xmit() function frees the mbuf). When we succeed we always call advance. The putback will always copy the mbuf back to the top of the ring. Note that the putback *cannot* be used with a drbr_dequeue() only with drbr_peek(). We most of the time, in putback, would not need to copy it back since most likey the mbuf is still the same, but sometimes xmit() functions will change the mbuf via a pullup or other call. So the optimial case for the single consumer is to always copy it back. If we ever do a multiple_consumer (for lagg?) we will need a test and atomic in the put back possibly a seperate putback_mc() in the ring buf. Reviewed by: jhb@freebsd.org, jlv@freebsd.org
* Use DEVMETHOD_END macro defined in sys/bus.h instead of {0, 0} sentinel on ↵sbz2013-01-301-1/+1
| | | | | | | device_method_t arrays Reviewed by: cognet Approved by: cognet
* Fixed mbuf free when receive structures fail to allocate.smh2013-01-121-2/+2
| | | | | | | | | This prevents quad igb card on high core machines, without any nmbcluster or igb queue tuning wedging the boot process if all nics are configured. Reviewed by: jfv Approved by: pjd (mentor) MFC after: 1 week
* Mechanically substitute flags from historic mbuf allocator withglebius2012-12-041-6/+6
| | | | malloc(9) flags in sys/dev.
* drbr_enqueue() awlays consumes mbuf, no matter did itglebius2012-11-261-27/+13
| | | | | | | | | | | | | | | fail or not. The mbuf pointer is no longer valid, so can't be reused after. Fix igb_mq_start() where mbuf pointer was used after drbr_enqueue(). This eventually leads us to all invocations of igb_mq_start_locked() called with third argument as NULL. This allows us to simplify this function. Submitted by: Karim Fodil-Lemelin <fodillemlinkarim gmail.com> Reviewed by: jfv
* This isn't functionally identical. In some cases a hint to disableeadler2012-10-221-0/+5
| | | | | | | | unit 0 would in fact disable all units. This reverts r241856 Approved by: cperciva (implicit)
* Now that device disabling is generic, remove extraneous code from theeadler2012-10-221-5/+0
| | | | | | | | device drivers that used to provide this feature. Reviewed by: des Approved by: cperciva MFC after: 1 week
* The drbr(9) API appeared to be so unclear, that most drivers inglebius2012-09-281-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | tree used it incorrectly, which lead to inaccurate overrated if_obytes accounting. The drbr(9) used to update ifnet stats on drbr_enqueue(), which is not accurate since enqueuing doesn't imply successful processing by driver. Dequeuing neither mean that. Most drivers also called drbr_stats_update() which did accounting again, leading to doubled if_obytes statistics. And in case of severe transmitting, when a packet could be several times enqueued and dequeued it could have been accounted several times. o Thus, make drbr(9) API thinner. Now drbr(9) merely chooses between ALTQ queueing or buf_ring(9) queueing. - It doesn't touch the buf_ring stats any more. - It doesn't touch ifnet stats anymore. - drbr_stats_update() no longer exists. o buf_ring(9) handles its stats itself: - It handles br_drops itself. - br_prod_bytes stats are dropped. Rationale: no one ever reads them but update of a common counter on every packet negatively affects performance due to excessive cache invalidation. - buf_ring_enqueue_bytes() reduced to buf_ring_enqueue(), since we no longer account bytes. o Drivers handle their stats theirselves: if_obytes, if_omcasts. o mlx4(4), igb(4), em(4), vxge(4), oce(4) and ixv(4) no longer use drbr_stats_update(), and update ifnet stats theirselves. o bxe(4) was the most correct driver, it didn't call drbr_stats_update(), thus it was the only driver accurate under moderate load. Now it also maintains stats itself. o ixgbe(4) had already taken stats from hardware, so just - drop software stats updating. - take multicast packet count from hardware as well. o mxge(4) just no longer needs NO_SLOW_STATS define. o cxgb(4), cxgbe(4) need no change, since they obtain stats from hardware. Reviewed by: jfv, gnn
* This patch fixes a nit in the em, lem, and igb driver statistics. Incrementsbruno2012-09-231-1/+1
| | | | | | | | | adapter->dropped_pkts instead of if_ierrors because if_ierrors is overwritten by hw stats collection. Submitted by: Andrew Boyer <aboyer@averesystems.com> Reviewed by: Jack F Vogel <jfv@freebsd.org> MFC after: 2 weeks
* Make the polling interface in igb able to handlejfv2012-08-061-19/+19
| | | | | | | multiqueue, and correct the rxdone handling. Update the polling man page to include igb as well. Thanks to Mark Johnston for these changes.
* Correct the mq_start routine to avoid out-of-orderjfv2012-08-061-3/+11
| | | | | | packet delivery, always enqueue when possible. Also correct the DEPLETED test as multiple bits might be set. Thanks to Randall Stewart for the changes!
* CPU_NEXT() already handles wrapping around to the beginning. Also, in asbruno2012-08-021-1/+0
| | | | | | | | | | system with sparse CPU IDs, you can have a valid CPU ID > mp_ncpus (e.g. if you have two CPUs 0 and 4, with mp_maxid == 4 and mp_ncpus == 2). Introduced at svn r235210 Submitted by: jhb@ Reviewed by: jfv@
* Change the interface to the Energy Efficient Ethernet (EEE)jfv2012-07-071-4/+28
| | | | | | | | | | | setting in the igb and em driver. This was necessitated by a shared code change that I was given late in the game, a data type changed from bool to int, in the last update I dealt with it by a cast, but it was pointed out (thanks jhb) that there was a potential problem with this. John suggested this safer approach, and it is fine with me... MFC after:2 days (to catch the 9.1 update)
* Correct small regressions pointed out by jhb, thanks John.jfv2012-07-051-3/+1
| | | | MFC after:5 days
OpenPOWER on IntegriCloud