Boosting Driver Performance with Kernel Plugins

In today’s high-performance computing environments, even a small inefficiency in driver architecture can lead to major bottlenecks. For developers working with custom hardware and device drivers, Jungo’s WinDriver offers a unique approach to maximizing throughput and responsiveness via Kernel Plugins (KPs). This post walks you through what Kernel Plugins are, why you should use them, and how to get started building one using WinDriver’s tools.

🧠 What is a Kernel Plugin?

A Kernel Plugin (KP) is a block of code that runs in kernel mode, giving it direct access to hardware and low-level resources. Unlike standard user-mode drivers that must constantly switch between user and kernel mode, KPs handle time-sensitive tasks like interrupts and DMA transfers directly in the kernel, avoiding costly context switches.

This architectural shift results in major performance gains, especially in high-speed applications.

🚀 Why Use a Kernel Plugin?

Here’s why Kernel Plugins are worth your attention:

  • Speed: Handle 100,000+ interrupts per second without missing a beat.
  • Efficiency: Eliminates the back-and-forth between user and kernel mode.
  • Portability: Same KP source code works across Windows, Linux, and macOS.
  • Safety: Develop and test logic in user mode first, then port to kernel mode—reducing crash risk.

🧱 Kernel Plugin Architecture

A Kernel Plugin runs independently of the user application, though the two communicate via message passing and callback functions.

Key interactions include:

  • Driver load
  • Handle request
  • Message call
  • Interrupt handling

✅ Tip: Use the high-level WDC_* API for most KP operations to simplify development and maintain portability.

🛠️ Building Your First Kernel Plugin

Follow these steps to get started:

  1. Use the PCI Diag Sample
    Located in the WinDriver installation folder, this is a fully working driver + KP example.
  2. Generate Your Driver
    Open the Driver Wizard GUI, scan your PCI device, and generate a new project. Enable the Kernel Plugin option during setup.
  3. Edit the Plugin Code
    The Wizard generates skeleton KP code. You’ll primarily edit kp_init, kp_call, and kp_int_handler.
  4. Message Passing
    Use WDC_CallKerPlug() in user mode to invoke your KP logic. Use shared headers to keep enums, struct names, and command codes synchronized between modes.

⚡ Interrupt Handling in Kernel Mode

Interrupts can overwhelm a user-mode driver. But in kernel mode:

  • You can process interrupts immediately.
  • Handle high IRQL tasks with minimal delay.
  • Offload lower-priority tasks using Deferred Procedure Calls (DPCs), keeping the system responsive.

Real-World Example

On Lattice’s CPNX and Avant FPGAs, switching to Kernel Plugin interrupt handling improved DMA throughput by over 100%.

✅ Best Practices

  • Develop in User Mode First
     Fully test and debug before moving any logic into the kernel.
  • Keep IRQL Sections Short
     Do the bare minimum in kpinthandler() and defer everything else.
  • Use Shared Headers
     Maintain one source of truth for constants, enums, and IOCTL codes across both layers.
  • Gradual Migration
     Don’t port everything at once. Move only critical functions into the KP.

Contact our team today to learn more about WinDriver.

Download WinDriver for free, and enjoy our 30-day trial.

Implementing DMA with WinDriver

The video provides a detailed guide on implementing Direct Memory Access (DMA) with WinDriver. It covers API usage, best practices, memory management, and interrupt handling. The emphasis is on using high-level APIs and the XDMA sample code to ensure efficiency and reliability.

Understanding Device Specifications

Before implementing a driver, users should thoroughly understand device specifications, offsets, and descriptor formats. For example, this is particularly relevant for Xilinx products. A proper grasp of the DMA start and completion mechanisms is also necessary for smooth implementation.

Key Topics Covered in the Video

The video offers a technical overview of DMA implementation using WinDriver, highlighting the following key aspects:

API Types in WinDriver

WinDriver provides two types of APIs:

  • High-level API (recommended): More advanced, easier to use, and operates in user mode.
  • Low-level API: Operates in kernel mode and requires more manual configuration.

Since the high-level API simplifies DMA handling, the focus remains on its functions, particularly WDC DMA scatter/gather buffer locking and unlocking, as well as interrupt handling.

Direct Memory Access Code Generation and Implementation

DMA implementation consists of several steps, including buffer allocation, locking, and closing the DMA process. To facilitate this, WinDriver provides APIs for:

  • Allocating memory
  • Transferring data
  • Managing interrupts

Users can specify key parameters, such as offsets, data to be transferred, and whether to use an interrupt handler.

Best Practices for DMA Implementation

For optimal DMA performance, follow these recommended steps:

  1. Allocate a user-mode buffer.
  2. Lock the buffer to ensure proper access control.
  3. Transfer data based on the required offsets.
  4. Close the DMA process after completion.

Additionally, scatter-gather DMA is a more advanced method that allows for efficient memory management.

Important Data Structures & Functions

The WDMA struct plays a crucial role in DMA handling, as it stores:

  • Buffer handles
  • User/kernel addresses
  • Buffer sizes
  • Alignment details

For reference, the XDMA sample code serves as an excellent template for building custom implementations.

Interrupt Handling vs. Polling Methods

DMA completion can be managed using two methods:

  • Polling Method: The system continuously checks for completion, which can be inefficient.
  • Interrupt Method (recommended): Uses an interrupt handler, which enhances efficiency.

By using the XDMA int enable function, users can configure interrupt handling in WinDriver for better performance.

CPU Cache Flushing for Direct Memory Access

Before and after a DMA transfer, it is essential to flush the CPU cache to prevent data corruption. This ensures clean data transfers and avoids inconsistencies.

Key functions that help with this process include:

  • DMA sync CPU
  • DMA sync I/O

Building a DMA Program

Once memory is allocated and locked, users must develop their own DMA program to manage data transfers. This program should clearly define:

  • What data needs to be transferred and where (specific offsets).
  • Whether to use an interrupt handler or polling for completion.
  • How to handle errors and logging during the transfer.

To simplify development, using the XDMA sample as a template is highly recommended.

By following these best practices and leveraging WinDriver’s high-level API, users can implement a robust and efficient DMA solution.

Please feel free to Contact our team today to learn more about WinDriver or Download WinDriver for free, and enjoy our 30-day trial.

Optimizing Data Transfer

Exploring Interrupt and Polling Mechanisms in DMA

In computer architecture, optimizing data transfer is essential for system performance. Direct Memory Access (DMA) controllers enable high-speed data movement between peripherals and memory without constant CPU involvement. A key decision in configuring DMA transfers is selecting the transfer flow sequence.

Polling Method DMA

Polling-based DMA requires the CPU to repeatedly check the DMA controller’s status to determine when a transfer is complete. The CPU polls the DMA controller at set intervals, usually via a status register or memory location. Once the transfer finishes, the CPU resumes its tasks.

Polling-based DMA is simple to implement since it does not require complex interrupt handling. It also offers determinism, as the CPU controls when polling occurs, which benefits real-time systems. Additionally, it incurs lower overhead than interrupts because it avoids context switching.

However, polling keeps the CPU occupied, reducing availability for other tasks. In systems with frequent DMA operations, this can hurt performance. Polling also introduces latency, as the CPU may not immediately detect completed transfers, delaying subsequent tasks. Infrequent or unpredictable data transfers further waste CPU cycles, leading to inefficiency.

Interrupt – Driven DMA

Interrupt-driven DMA notifies the CPU via an interrupt request (IRQ) when a transfer is complete. The CPU pauses its current task to handle the interrupt.

This method reduces CPU overhead, allowing it to handle other tasks while waiting for data transfers. It also minimizes latency by immediately signaling the CPU upon completion, making it ideal for time-sensitive applications. Additionally, by decoupling the CPU from data transfers, it enhances multitasking and system flexibility.

However, interrupt-driven DMA requires hardware support for interrupt handling, increasing system complexity and cost. In systems with multiple interrupts, priority inversion may occur if a low-priority DMA transfer delays higher-priority tasks. Handling interrupts also incurs overhead from context switching, which can affect performance in high-frequency scenarios.

Comparison

When comparing the two methods, interrupt-driven DMA generally offers better performance and responsiveness compared to polling-based DMA, especially in systems with high data transfer rates or stringent latency requirements. Polling-based DMA is simpler to implement but may not be suitable for high-performance or real-time systems. Interrupt-driven DMA, while more complex, offers greater flexibility and efficiency.

In terms of resource utilization, polling-based DMA ties up the CPU, leading to inefficient resource utilization, whereas interrupt-driven DMA allows the CPU to perform other tasks concurrently, improving overall system efficiency.

Both polling-based DMA and interrupt-driven DMA have their advantages and disadvantages, making them suitable for different use cases. The choice between these methods depends on the specific requirements of the system and the trade-offs between simplicity, performance, and flexibility.

Buffer Size

The buffer size plays a crucial role in DMA (Direct Memory Access) transfers as it directly impacts the efficiency, performance, and resource utilization of the system. The buffer size determines the amount of data that can be transferred in each DMA operation before the CPU is involved. 

A larger buffer size allows for fewer DMA transactions, reducing the overhead associated with DMA setup and teardown, and maximizing the throughput of the transfer. However, an excessively large buffer size can lead to wasted memory resources and increased latency if the DMA controller must wait for the buffer to fill before initiating a transfer. 

Conversely, a smaller buffer size may result in more frequent DMA transactions, potentially increasing CPU overhead and reducing overall system performance. Therefore, selecting an optimal buffer size is essential to achieve efficient data transfer, minimize latency, and maximize system throughput in DMA-based applications.

In a research we performed <Link>, we found that each DMA method has its sweet spot before it stagnates or gets to the point of diminishing performance. The x-axis shows the buffer size and the y-axis shows the transfer rate in MB/sec. The transfers were tested for 10 seconds each.

Scatter-Gather or Contiguous? Understanding DMA Types

In PCIe driver development, DMA (Direct Memory Access) facilitates data transfer between a PCIe device and system memory without involving the CPU. This transfer method significantly improves performance compared to CPU-mediated transfers, as it frees up the CPU for other tasks.

The basic DMA architecture includes 4 steps, defined and managed in the driver:

  1. Allocating a memory region accessible for DMA – This means the region (in the memory) that has specific properties that allow the device to directly read and write from it.
  2. Providing the physical address of the memory region to the device – The device translates this address into a format it understands for its DMA operations.
  3. Initiating the DMA transfer – The device uses its DMA controller to directly transfer data between its internal memory and the allocated memory region on the host system.
  4. Notifying when the transfer is complete – Freeing the allocated space, and processing the data or triggers further actions.

The memory allocation depends on various factors; the type of data transferred, device-memory compatibility, system architecture, and more. The actual free memory that can be allocated for the transfer is perhaps the most critical factor. Sometimes, there is not enough contiguous space to allocate to the DMA. 

Both contiguous and scatter-gather DMA (also: SG) are techniques used in PCIe driver development to efficiently transfer data between a device and system memory, but they differ in how they handle buffer allocation:

Contiguous DMA  – Pages a single segment of the memory, locking it to execute the transfer. Managing the transfer on the device side is easier, but it’s not always possible if sufficient contiguous memory isn’t allocated. This constraint is generally due to fragmentation.

Scatter-Gather DMA – Allocates multiple, potentially non-contiguous blocks of memory. The data fragments residing in memory are managed with a descriptor table, telling the device which data should go where. It is more complex to set up on the driver side as you need to manage the descriptor table.

So, which one is better?

As said, contiguous DMA is easier to program, debug and manage. However, SG DMA can be more effective when the requirements demand data scattered across multiple memory locations, in cases of large data transfers and when contiguous memory is scarce.

Regarding performance and speed, there is no straightforward answer. It depends on the device (and which DMA types the hardware supports), the memory (data patterns and available space) and the driver complexity. We recommend checking different methods, including DMA combined with polling and interrupts. Sometimes the results can be surprising. 

WinDriver, the leading cross-platform driver development toolkit for PCI/PCIe devices offers several tools making the development of both types of DMA easier. As a developer, you will be able to perform kernel operations (including DMA-related) from the user mode. Moreover, we offer an automated generated code based on settings defined in a GUI application (no-code). If you are new to this operation, WinDriver includes free samples of DMA run and tested for industry standard DMA IP Cores from companies such as Intel Altera, AMD Xilinx, Lattice, and more.

Want to learn more about WinDriver? Contact our team today.
Download WinDriver for free, and enjoy our 30-day trial.

Mastering Driver Development for High-Speed PCIe Devices

Nobody likes latency. The need for high speed and precise data transfer arises everywhere, from satellites orbiting space to data centers deep beneath the Earth’s surface. PCIe 7.0 is capable of transferring 128 GT/s, fulfilling the promise to double the I/O bandwidth every 3 years. 

One of the kernel developer’s goals is to utilize the hardware fully. It is not just about making everything work, but also maximizing the product’s potential. 

Optimize PCIe Devices: 4 Key Areas to Address

  • Use DMA – Perhaps the first thing we think of when it comes to data transfer speed is Direct Memory Access.
    DMA allows for direct data transfer between the device and memory, bypassing the CPU. This cuts down on latency and boosts throughput. Although it can be more challenging to set up a DMA mechanism, a properly implemented DMA significantly improves performance and reduces latency.
  • Implement Kernel Plugin – Kernel plugins are chunks of code (performing specific operations) that sit only in the kernel mode. The fact that they run without constantly context-switching with the user mode, makes their loading dynamic and operations faster. This not only affects the speed, but also demands less resources.
  • Optimize your code – A fine code can make all the difference, especially when there are a lot of “moving parts”. Coding an effective interrupt handler, managing multiple queues, optimizing memory access patterns, and other critical components can also enhance the device’s speed.
  • Update your OS version – The benefits of working with the latest version of an operating system do not stop at performance improvement. New versions often include critical security and other bug fixes, and better compatibility, support, and APIs. Research showed that newer versions enhance device performance.

Efficient data transfer with minimal latency is crucial across various applications. Kernel developers aiming to fully utilize their device potential must consider performance enhancement strategies like DMA, implementing Kernel Plugins, optimizing code, and working with an updated operating system. Ultimately contributing to enhanced device performance.

WinDriver, the most reliable driver development toolkit serving leading companies for more than 20 years, offers DMA, kernel plugins, and handlers API. Not just that, WinDriver comes with a sample folder, including tested interrupt handlers, DMA, and kernel plugin, and code samples for DMA IPs by AMD/Xilinx, Intel/Altera, and Lattice among others. Regarding coding, WinDriver offers no-code features, including generating code for I/O operations and predefined actions set in the DriverWizard. 

Want to learn more about WinDriver? Contact our team today.
Download WinDriver for free, and enjoy our 30-day trial.

Download WinDriver Free 30 Days Trial

Please fill the form below to download a fully featured WinDriver evaluation

Software License Agreement of WinDriver (TM) Version v16.4.0
© Jungo Connectivity Ltd. 2024 All Rights Reserved

IMPORTANT – READ CAREFULLY: THIS SOFTWARE LICENSE AGREEMENT (“AGREEMENT”) IS A LEGAL AGREEMENT BETWEEN YOU AND JUNGO CONNECTIVITY LTD. (“JUNGO”), FOR THE WINDRIVER SOFTWARE PRODUCT ACCOMPANYING THIS LICENSE (THE “SOFTWARE”). BY INSTALLING, COPYING OR OTHERWISE USING THE SOFTWARE, YOU AGREE TO BE LEGALLY BOUND BY THE TERMS AND CONDITIONS OF THIS AGREEMENT. IF YOU DO NOT AGREE TO THE TERMS AND CONDITIONS OF THIS AGREEMENT, DO NOT INSTALL, COPY, OR OTHERWISE USE THE SOFTWARE.

 

  1. OWNERSHIP OF THE SOFTWARE. All right, title, and interest in and to the Software, including associated intellectual property rights, of any sort and/or kind, are and shall remain solely with Jungo and its licensors, and may be protected by copyright, trademark, patent and trade secret law and international treaties. This Agreement does not convey to you an interest in or to the Software, but only a limited, non-transferable, non-sublicensable, non-exclusive, and revocable right of use, in accordance with the terms of this Agreement. You may not remove any proprietary notices and/or any legends from the Software, in whole or in part.

 

  1. GRANT OF LICENSE. Jungo hereby grants you a personal, non-exclusive, nontransferable, non-sublicensable node-locked and time limited license to use the Software.

 

    – Individuals: Jungo grants you, as an individual, a personal, non-exclusive, “single-user” license to use the Software on a single computer, in the manner provided below, at the site for which the license was given.

 

    – Entities: If you are an entity, Jungo grants you the right to designate one individual within your organization (and only one) to have the right to use the Software on a single computer, in the manner provided below, at the site for which the license was given.

 

    – License Scope: A single user license allows usage of WinDriver and redistribution of certain components (as defined below) within a single end product SKU, for a single device (identified by its VID/PID (USB) or VID/DID (PCI)), and without SDK/API capabilities.  If you need extended license or distribution rights, please contact Jungo.

 

  1. EVALUATION LICENSE. If you have not yet paid license fees for the use of the Software, then Jungo hereby grants you a personal, non-exclusive, non-transferable and non-sublicensable license to internally use the Software for evaluation purposes only, for a period of 30 days (the “Evaluation License”). If, after the expiration of the Evaluation License, you wish to continue using the Software and accompanying written materials, you may do so by remitting the required payment to Jungo, and you will then receive a registration code and a license string that will permit you to use the Software on a single computer under one of the license schemes specified in Section 2 above.

 

  1. SERVICE OPTIMIZATION AND ENHANCEMENT. To continuously improve and optimize Jungo’s services, Jungo reserves the right to anonymously monitor, collect, and analyze usage data, including but not limited to API interactions, performance metrics, and system activity. Such data collection and analysis shall be conducted in compliance with all applicable laws and regulations and shall be used solely for the purpose of enhancing service performance, security, and reliability.
  2. SUBSCRIPTION, SERVICE CONTINUITY, RENEWAL, AND LATE PAYMENT PENALTIES. Access to the WinDriver and its associated features is provided on a subscription basis, subject to annual renewal. Failure to renew the subscription before the expiration date may result in the automatic termination of access to the platform and all related services, and additional fees (including but not limited to late payment penalties, administrative charges, or reinstatement costs). Upon termination, the user shall forfeit any rights to continued use, and we reserve the right to suspend or delete any associated accounts, data, or functionalities without further notice.

 

  1. OPEN SOURCE. The Software includes certain files that are subject to open source licenses. These files are identified in their header files (“Open Source Files”). You must use the Open Source Files in accordance with the terms of their respective licenses.  In the event of any contradiction between the terms of this Agreement, and the terms of the open source license accompanying a certain Open Source File, the terms of the latter shall prevail, with regard to the said Open Source File.

 

RESTRICTIONS ON USE AND TRANSFER

 

  1. DISTRIBUTION OF FILES.

 

    (a) You may not distribute, or otherwise transfer or assign, any portion of the Software, including any of the headers or source files that are included in the Software, unless otherwise expressly permitted in this Agreement, subject to the provisions of Section 4 above.

 

    (b) Subject to your full and continued compliance with the terms of this Agreement, including the ongoing payment of annual license fees, you may distribute the following files:

 

Windows:
-windrvr1640.sys
-windrvr1640_legacy.sys
-windrvr1640.inf
-windrvr1640.cat
-wdapi1640.dll
-wdapi1640_32.dll
-wdapi1640_arm64.dll
-wdapi_dotnet1640.dll
-wdapi_dotnet1640_32.dll
-wdapi_netcore1640.dll
-wdapi_java1640.dll
-wdapi_java1640.jar
-wdreg.exe
-difxapi.dll
-devcon.exe
-windrvr1630.sys
-windrvr1630.inf
-wd1630.cat
-wdapi1630.dll
-wdapi_dotnet1630.dll
-wdapi_java1630.dll wdapi_java1600.jar
-windrvr1220.dll
-wdapi1220.dll

Linux:
-windrvr_gcc_v3.o_shipped
-windrvr_gcc_v3_regparm.o_shipped
-kp_linux_gcc_v3.o
-kp_linux_gcc_v3_regparm.o
-libwdapi1640.so libwdapi1640_32.so
-libwdapi_java1640.so
-libwdapi_java1640_32.so
-wdapi_java1640.jar
-wdapi_netcore1640.dll
-kp_wdapi1640_gcc_v3.o_shipped
-kp_wdapi1640_gcc_v3_regparm.o_shipped
-linux_wrappers.c
-linux_wrappers.h
-wdusb_linux.c
-wdusb_interface.h
-wd_ver.h
-linux_common.h
-windrvr.h
-windrvr_usb.h
-wdsriov_interface.h
-wdsriov_linux.c
-wdreg
-configure makefile.in
-configure.wd makefile.wd.in
-makefile.wd.kbuild.in
-configure.usb
-makefile.usb.in
-makefile.usb.kbuild.in
-setup_inst_dir
-windrvr_gcc_v2.a windrvr_gcc_v3.a windrvr_gcc_v3_regparm.a
-kp_linux_gcc_v2.o kp_linux_gcc_v3.o kp_linux_gcc_v3_regparm.o
-libwdapi1630.so
-libwdapi_java1630.so wdapi_java1600.java
-kp_wdapi1630_gcc_v2.a kp_wdapi1600_gcc_v3.a kp_wdapi1600_gcc_v3_regparm.a
-linux_wrappers.c linux_wrappers.h wdusb_linux.c
-wdusb_interface.h wd_ver.h linux_common.h windrvr.h windrvr_usb.h
-configure.wd makefile.wd.in makefile.wd.kbuild.in
-configure.usb makefile.usb.in makefile.usb.kbuild.in

macOS:
-libwdapi1640.dyld
-libwdapi_java1640.jar
-libwdapi_java1640.dyld
-wdapi_netcore1640.dll
-WinDriver1640.kext
-WinDriver1640.dext
-wd_mac_install.sh
-wd_mac_uninstall.sh

 

    (c) The files listed in Section 5.b above may be distributed only as part of a complete application that you distribute under your organization name, and only if they significantly contribute to the functionality of your application. For avoidance of doubt, each organization distributing these files as part of the organization products is required to have valid license(s) under the organization name/VID, irrespective of the party who actually performed the product development. Licenses granted to subcontractors do not grant distribution or other rights to the organizations for which they are developing.

 

    (d) The distribution of the windrvr.h header file is permitted only on Linux.

 

    (e) You may not modify the distributed files specified in Section 5.b of this Agreement.

 

    (f) You may not distribute any header file that describes the WinDriver functions, or functions that call the WinDriver functions and have the same basic functionality as that of the WinDriver functions.

 

  1. The Software may not be used to develop a development product, an API, or any products, which will eventually be part of a development product or environment, without the written consent of Jungo and subject to additional fees and licensing terms.

 

  1. You may make printed copies of the written materials accompanying the Software, provided that only users bound by this license use them.

 

  1. You may not allow any third party to use the Software, grant access to the Software (or any portion thereof) to any third party, or otherwise make any commercial use of the Software, including without limitation, assign, distribute, sublicense, transfer, pledge, lease, rent, or share your rights in the Software or any of your rights under this Agreement, all whether or not for any consideration.

 

  1. You may not translate, reverse engineer, decompile, disassemble, reproduce, duplicate, copy, or otherwise disseminate all or any part of the Software, or extract source code from the object code of the Software.

 

  1. Jungo reserves the right to revise, update, change, modify, add to, supplement, or delete any and all terms of this License Agreement; provided, however, that changes to this License Agreement will not be applied retroactively. Such changes will be effective with or without prior notice to you. You can review the most current version of this License Agreement under the WinDriver download form page.

 

  1. You may not incorporate or link any open source software with any open source software part of the Software, or otherwise take any action which may cause the Software or any portion thereof to be subjected to the terms of the Free Software Foundation’s General Public License (GPL) or Lesser General Public License (LGPL), or of any other open source code license.

 

  1. DISCLAIMER OF WARRANTY. THIS SOFTWARE AND ITS ACCOMPANYING WRITTEN MATERIALS ARE PROVIDED BY JUNGO “AS IS” WITHOUT ANY WARRANTY. ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT, ARE HEREBY DISCLAIMED TO THE FULLEST EXTENT PERMITTED UNDER APPLICABLE LAW.

 

  1. NO LIABILITY. TO THE FULLEST EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL JUNGO OR ITS LICENSORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, SAVINGS, IP INFRINGEMENT OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

 

  1. Governing Law. This Agreement and use of the Software are governed by the laws of the State of Israel, regardless of its conflict of laws rules, and the competent courts of the State of Israel shall have sole and exclusive jurisdiction over any dispute under this Agreement or otherwise related to the Software.

 

  1. Confidentiality. The Software, including any additional information related thereto, contains confidential and proprietary information of Jungo.  Accordingly, you agree that you will not, nor allow any third party to, disseminate, transfer, grant access to, or otherwise disclose to any third party the Software or any part thereof or any other confidential or proprietary information of Jungo provided in connection therewith. You will maintain all copies of the Software and all related documentation in confidence.

 

  1. Termination and Effects of Termination. Jungo may terminate this Agreement and the licenses granted to you hereunder at any time if you breach any of your obligations hereunder, by issuance of written notice to such effect, addressed to you at the address you provided in your registration form. Upon expiration or other termination of this Agreement, the Licenses granted to you hereunder shall immediately and automatically be canceled, and you will immediately remove all copies of the Software from your computer(s) and cease any use thereof.

 

  1. Contact Details. If you have any questions concerning this Agreement or wish to contact Jungo for any reason —

 

          Web site: https://www.jungo.com

          Email:    [email protected]

 

  1. US GOVERNMENT RESTRICTED RIGHTS. The Software and documentation are provided with RESTRICTED RIGHTS.

  Use, duplication, or disclosure by the Government is subject to restrictions set forth in subparagraph (c)(1) of The Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 or subparagraphs (c)(1)(ii) and (2) of Commercial Computer Software – Restricted Rights at 48 CFR 52.227-19, as applicable.

 

  1. Automatic Renewal. The subscription shall be automatically renewed, unless Licensee notifies Licensor 30 days or more prior to the expiration date of the subscription, of its intent not to renew the subscription.

Accessibility Toolbar