On 18-09-29 07:03:33, Yongseok Koh wrote:
> On Tue, Sep 25, 2018 at 07:51:06PM +0800, Xiaoyu Min wrote:
> > Offload the following rte_flow actions by inserting accordingly
> > E-Switch rules via TC Flower driver
> >
> > - RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC
> > - RTE_FLOW_ACTION_TYPE_SET_IPV4_DST
Hello Stephen,
I looked at KNI code again, memcpy is already used everywhere
(kni_net_header, kni_net_rebuild_header) for MAC address copy.
So I propose to accept the patch as it is.
memcpy can be replaced by ether_addr_copy in all functions at once in
separate patch.
Igor
On Sat, Sep 29, 2018
29/09/2018 08:43, Zhang, Qi Z:
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> >
> > Hi,
> >
> > 03/09/2018 10:40, Qi Zhang:
> > > When scanning an already plugged device, the virtual address of mapped
> > > PCI resource in rte_pci_device will be overridden with 0, that may
> > > cause dri
On Sat, 2018-09-29 at 13:00 +0100, Hari Kumar Vemula wrote:
> 1/4: enablement of aesni_gcm pmd in meson
> 2/4: enablement of aesni_mb pmd in meson
> 3/4: enablement of kasumi pmd enable in meson
> 4/4: enablement of zuc pmd enable in meson
>
> Hari Kumar Vemula (4):
> driver/crypto: enable meson
Hotplug is an important feature for use-cases like the datacenter device's
fail-safe and for SRIOV Live Migration in SDN/NFV. It could bring higher
flexibility and continuality to networking services in multiple use-cases
in the industry. So let's see how DPDK can help users implement hotplug
solut
This patch implements the ops to handle hot-unplug on the PCI bus.
For UIO PCI, it could avoids BARs read/write errors by creating a
new dummy memory to remap the memory where the failure is. For VFIO
or other kernel driver, it could specific implement function to handle
hot-unplug case by case.
S
When a device is hot-unplugged, a sigbus error will occur of the datapath
can still read/write to the device. A handler is required here to capture
the sigbus signal and handle it appropriately.
This patch introduces a bus ops to handle sigbus errors. Each bus can
implement its own case-dependent
A hot-unplug failure and app crash can be caused, when a device is
hot-unplugged but the application still try to access the device
by reading or writing from the BARs, which is already invalid but
still not timely be unmap or released.
This patch introduces bus ops to handle hot-unplug failures.
The mechanism can initially register the sigbus handler after the device
event monitor is enabled. When a sigbus event is captured, it will check
the failure address and accordingly handle the memory failure of the
corresponding device by invoke the hot-unplug handler. It could prevent
the applicat
This patch use testpmd for example, to show how an app smoothly handle
failure when device be hot-unplug. Except app should enabled the device
event monitor and register the hotplug event’s callback, it also need
enable hotplug handle mechanism before running. Once app detect the
removal event, the
This patch implements the ops for the PCI bus sigbus handler. It finds the
PCI device that is being hot-unplugged and calls the relevant ops of the
hot-unplug handler to handle the hot-unplug failure of the device.
Signed-off-by: Jeff Guo
Acked-by: Shaopeng He
---
v11->v10:
change commit log.
--
This patch aims to add a helper to iterate over all buses to find the
relevant bus to handle the sigbus error.
Signed-off-by: Jeff Guo
Acked-by: Shaopeng He
---
v11->v10:
change some words.
---
lib/librte_eal/common/eal_common_bus.c | 43 ++
lib/librte_eal/common
On 9/26/2018 8:20 PM, Burakov, Anatoly wrote:
On 17-Aug-18 11:51 AM, Jeff Guo wrote:
This patch modify the device event callback process function name to be
more explicit, and exposure the API from private to public. The drivers
and apps would directly use this API to process device event call
On 9/26/2018 8:20 PM, Burakov, Anatoly wrote:
On 17-Aug-18 11:51 AM, Jeff Guo wrote:
This patch modify the device event callback process function name to be
more explicit, and exposure the API from private to public. The drivers
and apps would directly use this API to process device event call
This patch implements the ops for the PCI bus sigbus handler. It finds the
PCI device that is being hot-unplugged and calls the relevant ops of the
hot-unplug handler to handle the hot-unplug failure of the device.
Signed-off-by: Jeff Guo
Acked-by: Shaopeng He
---
v11->v10:
change commit log.
--
A hot-unplug failure and app crash can be caused, when a device is
hot-unplugged but the application still try to access the device
by reading or writing from the BARs, which is already invalid but
still not timely be unmap or released.
This patch introduces bus ops to handle hot-unplug failures.
When a device is hot-unplugged, a sigbus error will occur of the datapath
can still read/write to the device. A handler is required here to capture
the sigbus signal and handle it appropriately.
This patch introduces a bus ops to handle sigbus errors. Each bus can
implement its own case-dependent
Hotplug is an important feature for use-cases like the datacenter device's
fail-safe and for SRIOV Live Migration in SDN/NFV. It could bring higher
flexibility and continuality to networking services in multiple use-cases
in the industry. So let's see how DPDK can help users implement hotplug
solut
This patch implements the ops to handle hot-unplug on the PCI bus.
For UIO PCI, it could avoids BARs read/write errors by creating a
new dummy memory to remap the memory where the failure is. For VFIO
or other kernel driver, it could specific implement function to handle
hot-unplug case by case.
S
The mechanism can initially register the sigbus handler after the device
event monitor is enabled. When a sigbus event is captured, it will check
the failure address and accordingly handle the memory failure of the
corresponding device by invoke the hot-unplug handler. It could prevent
the applicat
This patch aims to add a helper to iterate over all buses to find the
relevant bus to handle the sigbus error.
Signed-off-by: Jeff Guo
Acked-by: Shaopeng He
---
v11->v10:
change some words.
---
lib/librte_eal/common/eal_common_bus.c | 43 ++
lib/librte_eal/common
This patch use testpmd for example, to show how an app smoothly handle
failure when device be hot-unplug. Except app should enabled the device
event monitor and register the hotplug event’s callback, it also need
enable hotplug handle mechanism before running. Once app detect the
removal event, the
As we may know that the process of hotplug is different between igb_uio
and vfio. For igb_uio, it could use uevent notification and memory
failure handle mechanism for hot-unplug. But for vfio, when device is be
hot-unplugged, the uevent can not be detected immediately, because of the
vfio kernel m
Add a new req notifier in eal interrupt for enable vfio hotplug.
Signed-off-by: Jeff Guo
---
v2->v1:
no change
---
lib/librte_eal/common/include/rte_eal_interrupts.h | 1 +
lib/librte_eal/linuxapp/eal/eal_interrupts.c | 71 ++
2 files changed, 72 insertions(+)
diff --
This patch modify the device event callback process function name to be
more explicit, change the variable to be const and exposure the API out
from private eal. The bus drivers and eal device would directly use this
API to process device event callback.
Signed-off-by: Jeff Guo
---
v2->v1:
change
When device is be hot-unplugged, the vfio kernel module will sent req
notifier to request user space to release the allocated resources at
first. After that, vfio kernel module will detect the device disappear,
and then delete the device in kernel.
This patch aim to add req notifier processing to
There are some extended interrupt types in vfio pci device except from the
existing interrupts, such as err and req notifier, they could be useful for
device error monitoring. And these corresponding interrupt handler is
different from the other interrupt handler that register in PMDs, so a new
int
Hi Jeff,
>
> The mechanism can initially register the sigbus handler after the device
> event monitor is enabled. When a sigbus event is captured, it will check
> the failure address and accordingly handle the memory failure of the
> corresponding device by invoke the hot-unplug handler. It could
Hi Akhil,
>
> Hi Konstantin,
>
> On 9/24/2018 4:21 PM, Ananyev, Konstantin wrote:
> > Hi Akhil,
> >
> >> Hi Konstantin,
> >>
> >> On 9/18/2018 6:12 PM, Ananyev, Konstantin wrote:
> > I am not saying this should be the ONLY way to do as it does not work
> > very well with non NPU/FPGA c
>
> Some general comments for the various __atomic_store/load added,
>
> 1. Although it passes the compiler check, but I just want to confirm that if
> we
> should use GCC/clang builtins, or if There are higher level APIs in DPDK to do
> atomic operations?
>
I have used gcc builtins (just like
> > > >
> > > >Reader-writer concurrency issue, caused by moving the keys to their
> > > >alternative locations during key insert, is solved by introducing a
> > > >global counter(tbl_chng_cnt) indicating a change in table.
>
>
>
> > > > /**
> > > >@@ -200,7 +200,7 @@ rte_hash_add_key_with_has
> >
> >Reader-writer concurrency issue, caused by moving the keys to their
> >alternative locations during key insert, is solved by introducing a
> >global counter(tbl_chng_cnt) indicating a change in table.
> >
> >@@ -662,6 +679,20 @@ rte_hash_cuckoo_move_insert_mw(const struct
> rte_hash *h,
> >
> >
> >Add the flag to enable reader-writer concurrency during run time. The
> >rte_hash_del_xxx APIs do not free the keystore element when this flag
> >is enabled. Hence a new API, rte_hash_free_key_with_position, to free
> >the key store element is added.
> >
> >+/** Flag to support lock free rea
>
> On 9/19/2018 2:42 PM, dev-boun...@dpdk.org wrote:
> > With existing code in kni_fifo_put, rx_q values are not being updated
> > before updating fifo_write. While reading rx_q in kni_net_rx_normal,
> > This is causing the sync issue on other core. The same situation
> > happens in kni_fifo_get
34 matches
Mail list logo
