> Subject: RE: [EXTERNAL] Re: [Patch v3 6/6] bus/vmbus: set event for channel
> without monitoring support
>
> > Subject: [EXTERNAL] Re: [Patch v3 6/6] bus/vmbus: set event for
> > channel without monitoring support
> >
> > On Fri, 4 Apr 2025 17:35:38 -0700
> > lon...@linuxonhyperv.com wrote:
> >
> Subject: [EXTERNAL] Re: [Patch v3 6/6] bus/vmbus: set event for channel
> without
> monitoring support
>
> On Fri, 4 Apr 2025 17:35:38 -0700
> lon...@linuxonhyperv.com wrote:
>
> > diff --git a/drivers/bus/vmbus/vmbus_channel.c
> > b/drivers/bus/vmbus/vmbus_channel.c
> > index bccef168d3..81e
> Subject: [EXTERNAL] Re: [patch v4 6/6] bus/vmbus: set event for channel
> without
> monitoring support
>
> On Mon, 7 Apr 2025 15:45:04 -0700
> lon...@linuxonhyperv.com wrote:
>
> > From: Long Li
> >
> > For vmbus channels without monitoring support, u
> Subject: [EXTERNAL] Re: [Patch v3 6/6] bus/vmbus: set event for channel
> without
> monitoring support
>
> On Fri, 4 Apr 2025 17:35:38 -0700
> lon...@linuxonhyperv.com wrote:
>
> > diff --git a/drivers/bus/vmbus/vmbus_channel.c
> > b/drivers/bus/vmbus/vmbus_channel.c
> > index bccef168d3..81e
> > > Subject: [EXTERNAL] [PATCH] net/netvsc: add stats counters from VF
> > >
> > > From: Long Li
> > >
> > > The netvsc driver should add per-queue and rx_nombuf counters from VF.
> > >
> > > Fixes: 4e9c73e96e83 ("net/netvsc:
> Subject: Re: [EXTERNAL] Re: [patch v2 0/6] Support VMBUS channels without
> monitoring enabled
>
> On Wed, 12 Mar 2025 00:33:52 +0000
> Long Li wrote:
>
> > > Subject: [EXTERNAL] Re: [patch v2 0/6] Support VMBUS channels
> > > without monitoring enabled
&
> -Original Message-
> From: David Marchand
> Sent: Monday, March 17, 2025 2:47 AM
> To: lon...@linuxonhyperv.com
> Cc: Stephen Hemminger ; Wei Hu
> ; Thomas Monjalon ;
> dev@dpdk.org; Long Li
> Subject: [EXTERNAL] Re: [Patch v2] doc: announce bus/vmbus API cha
> Subject: [EXTERNAL] Re: [PATCH] doc: announce bus/vmbus API changes
>
> 12/03/2025 22:43, lon...@linuxonhyperv.com:
> > From: Long Li
> >
> > All vmbus APIs are used internally by DPDK core and net/netvsc PMD.
> > It's not feasible or practical to use th
> Can't take it as is, here are some options:
>
> 1. Version the API even though should only be used internally. Use API
> versioning
>as transistion until 25.11.
> 2. Wait for 25.11 and just fix it now, and do deprecation notice now.
>
> 3. Mark the API's as internal (in 25.11) and do depre
> Subject: [EXTERNAL] Re: [patch v2 0/6] Support VMBUS channels without
> monitoring enabled
>
> On Mon, 10 Mar 2025 14:42:51 -0700
> lon...@linuxonhyperv.com wrote:
>
> > From: Long Li
> >
> > Hyperv may expose VMBUS channels without monitoring enabled. In t
> Subject: [EXTERNAL] Re: [PATCH 6/6] bus/vmbus: set event for channel
> without monitoring support
>
> On Thu, 27 Feb 2025 17:09:01 -0800
> lon...@linuxonhyperv.com wrote:
>
> > From: Long Li
> >
> > For vmbus channels without monitoring support, use kernel
> -Original Message-
> From: Wei Hu
> Sent: Tuesday, February 18, 2025 10:12 PM
> To: lon...@linuxonhyperv.com; Stephen Hemminger
>
> Cc: dev@dpdk.org; Long Li ; sta...@dpdk.org
> Subject: RE: [EXTERNAL] [PATCH] net/netvsc: add stats counters from VF
>
>
&
> Subject: Re: [PATCH] net/mana: avoid the use of variable length array
>
> On Tue, Mar 04, 2025 at 04:37:32PM -0800, lon...@linuxonhyperv.com wrote:
> > From: Long Li
> >
> > The pathname can be defined as name[MAX_PATH]. This makes the driver
> > compilable
> Subject: [EXTERNAL] Re: [Patch v3] net/mana: use mana_local_data for tracking
> usage data for primary process
>
> On Thu, 20 Feb 2025 15:32:02 -0800
> lon...@linuxonhyperv.com wrote:
>
> > From: Long Li
> >
> > The driver uses mana_shared_data for tracking
> The DPDK has converted to using the C11 atomic's so this should use that (i.e
> RTE_ATOMIC() etc) instead of the older atomic primitives.
>
I have sent v3.
> On Fri, 7 Feb 2025 15:21:45 -0800
> lon...@linuxonhyperv.com wrote:
>
> > + /* At least one eth_dev is probed, init shared data */
> > + if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
> > + rte_spinlock_lock(&mana_shared_data_lock);
> > + mana_local_data.primary_cnt++
> Subject: [EXTERNAL] [PATCH 1/4] net/netvsc: scan all net devices under the PCI
> device
>
> From: Long Li
>
> The current code has the wrong assumption that a PCI device can have only one
> Ethernet device. This is not correct as a PCI device can be multi functional
> From: Stephen Hemminger
> Sent: Wednesday, January 29, 2025 7:59 PM
> To: Long Li
> Cc: lon...@linuxonhyperv.com; Ferruh Yigit ; Andrew
> Rybchenko ; Wei Hu ;
> dev@dpdk.org
> Subject: Re: [EXTERNAL] Re: [PATCH 4/4] net/netvsc: cache device parameters
> for hot plug ev
> -Original Message-
> From: Stephen Hemminger
> Sent: Tuesday, January 28, 2025 4:32 PM
> To: Long Li
> Cc: lon...@linuxonhyperv.com; Ferruh Yigit ; Andrew
> Rybchenko ; Wei Hu ;
> dev@dpdk.org
> Subject: Re: [EXTERNAL] Re: [PATCH 4/4] net/netvsc: cache dev
> Subject: [EXTERNAL] Re: [PATCH 4/4] net/netvsc: cache device parameters for
> hot plug events
>
> On Mon, 27 Jan 2025 17:35:06 -0800
> lon...@linuxonhyperv.com wrote:
>
> > @@ -1409,9 +1424,6 @@ eth_hn_dev_uninit(struct rte_eth_dev *eth_dev)
> > ret_stop = hn_dev_stop(eth_dev);
> > hn_d
te[RTE_MAX_QUEUES_PER_PORT];
> | ^~
>
> To fix this, a hint is added to the network drivers where a compiler in the
> CI has
> been seen to emit the above error when DPDK is configured for one queue per
> port, but we know that the error cannot
> Subject: Re: [Patch v5] net/netvsc: fix number Tx queues > Rx queues
>
> On Thu, 17 Oct 2024 12:20:29 -0700
> lon...@linuxonhyperv.com wrote:
>
> > +static void
> > +hn_rx_queue_free_common(struct hn_rx_queue *rxq) {
> > + if (!rxq)
> > + return;
> > +
> > + rte_free(rxq->rxbuf_in
> This version of the patch is garbled in patchwork which means the CI test
> never
> ran because patch would not apply.
>
> You need cleanup and resubmit it.
I have sent v5 on behalf of Alan.
getting included and net/mana is successfully enabled.
>
> Fixes: 517ed6e2d590 ("net/mana: add basic driver with build environment")
> Cc: lon...@microsoft.com
> Cc: sta...@dpdk.org
> Signed-off-by: Shreesh Adiga <16567adigashre...@gmail.com>
Acked-by: Long Li
; &reserved=0
>
> >
> > Optimizing for multicast packets is not worth bothering.
>
> Optimizing for multicast/broadcast comes into play in multicast environments,
> and during network broadcast storms.
> Although I don't know if any of those two scenarios are relevant for this
> specific
> driver.
>
> > Keep the original code it is simpler.
>
> Let's keep similar code similar across drivers.
>
> @Long, @Wei, please Review/Ack, so the patch can be applied.
Reviewed-by: Long Li
> I released this mail from the moderation queue, so the patch could make it to
> patchwork.
>
> > The sender is lon...@linuxonhyperv.com, the author is
> lon...@microsoft.com. I hope that is okay.
>
> The @linuxonhyperv.com address one is not registered to the dev ml, which is
> the reason why
> > Hi Long,
> >
> > I don't see this patch in the mail list and patchwork, it can be
> > because of the email address it has been sent, fyi.
>
> The mail was waiting in the moderation queue.
> Long, please fix your send-email setup, or send with a mail address registered
> to the dev@ ml.
I thin
> Subject: [PATCH] netvsc: optimize stats counters performance
>
> Optimized the performance of updating the statistics counters by reducing the
> number of branches.
>
> Ordered the packet size comparisons according to the probability with typical
> internet traffic mix.
>
> Signed-off-by: Mort
Hi Vladimir,
Is there another way that you can determine the device probe order from your
application? (like going through the /sys/class/uio devices)
Long
From: Vladimir Ratnikov
Sent: Tuesday, June 25, 2024 4:50 AM
To: Stephen Hemminger
Cc: Long Li ; dev@dpdk.org
Subject: Re: [PATCH v2
Fixes: 45c83603087e (“net/netvsc: support MTU set”)
Cc: sta...@dpdk.org<mailto:sta...@dpdk.org>
From: Sam Andrew
Sent: Wednesday, July 3, 2024 3:50 PM
To: Alexander Skorichenko ; Long Li
Cc: step...@networkplumber.org; ferruh.yi...@amd.com;
andrew.rybche...@oktetlabs.ru; Wei Hu ; dev@dp
Thank you, Alexander.
The patch looks good to me. With this patch, do you see other problems with VPP?
I'd like to get a review from @Sam Andrew<mailto:samand...@microsoft.com>.
Acked-by: Long Li
From: Alexander Skorichenko
Sent: Tuesday, July 2, 2024 1:49 AM
To: step...@network
> Subject: [PATCH 1/1] maintainers: update for vmbus/mana/netvsc drivers
>
> Add myself as maintainer for vmbus, mana and netvsc.
>
> Signed-off-by: Wei Hu
Reviewed-by: Long Li
> ---
> MAINTAINERS | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/MAI
ithout getting ifname we ret
> shouldn't have an arbitrary value.
>
> Coverity issue: 424690
> Fixes: 84497839d9ca ("net/mana: support MTU update")
> Cc: lon...@microsoft.com
>
> Signed-off-by: Mahmoud Maatuq
Reviewed-by: Long Li
> ---
> v4:
> * used f
finished the loop without getting ifname we ret
> shouldn't have an arbitrary value.
>
> Coverity issue: 424690
> Fixes: 84497839d9ca ("net/mana: support MTU update")
> Cc: lon...@microsoft.com
>
> Signed-off-by: mmaatuq
Thank you.
Reviewed-by: Long Li
> This introduced additional check in Rx path, not sure what is the performance
> impact.
>
> I can see Long already acked the v3, I just want to double check.
> If Tx queue number > Rx queue number is not a common usecase, perhaps it can
> be an option to forbid it instead of getting performanc
> static inline void
> vmbus_set_monitor(const struct vmbus_channel *channel, uint32_t monitor_id)
> {
> - uint32_t *monitor_addr, monitor_mask;
> + RTE_ATOMIC(uint32_t) *monitor_addr, monitor_mask;
Does this mean monitor_mask will also change to RTE_ATOMIC(uint32_t)?
Seems not necessa
> > The usage is okay. The value is used to notify the VSP (Hyper-V). It's
> > always set
> (no read) from DPDK.
> >
>
> OK, so my question was not "does it need to be atomic", but rather "why isn't
> it
> marked RTE_ATOMIC() when it's treated as atomic".
>
> But what you are saying is that i
> > static inline void
> > vmbus_set_monitor(const struct vmbus_channel *channel, uint32_t
> monitor_id)
> > {
> > - uint32_t *monitor_addr, monitor_mask;
> > + RTE_ATOMIC(uint32_t) *monitor_addr, monitor_mask;
> > unsigned int trigger_index;
> >
> > trigger_index = monitor_id /
eived on them.
>
> Fixes: 4e9c73e96e83 ("net/netvsc: add Hyper-V network device")
> Cc: sthem...@microsoft.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Alan Elder
Reviewed-by: Long Li
> Subject: [PATCH v3 1/1] net/mana: add vlan tagging support
>
> For tx path, use LONG_PACKET_FORMAT if vlan tag is present. For rx, extract
> vlan
> id from oob, put into mbuf and set the vlan flags in mbuf.
>
> Signed-off-by: Wei Hu
Acked-by: Long Li
> ---
>
&
> --- a/drivers/net/mana/rx.c
> +++ b/drivers/net/mana/rx.c
> @@ -532,6 +532,21 @@ mana_rx_burst(void *dpdk_rxq, struct rte_mbuf **pkts,
> uint16_t pkts_n)
> mbuf->hash.rss = oob-
> >packet_info[pkt_idx].packet_hash;
> }
>
> + if (oob->rx_vlan_tag_pr
> a/drivers/net/netvsc/hn_rxtx.c b/drivers/net/netvsc/hn_rxtx.c index
> 9bf1ec5509..c0aaeaa972 100644
> --- a/drivers/net/netvsc/hn_rxtx.c
> +++ b/drivers/net/netvsc/hn_rxtx.c
> @@ -243,6 +243,7 @@ hn_dev_tx_queue_setup(struct rte_eth_dev *dev, {
> struct hn_data *hv = dev->data->dev_private
> Subject: Re: [PATCH] net/netvsc: fix number Tx queues > Rx queues
>
> On Thu, 29 Feb 2024 19:29:11 +
> Alan Elder wrote:
>
> > The previous code allowed the number of Tx queues to be set higher
> > than the number of Rx queues. If a packet was sent on a Tx queue with
> > index
> > >= numb
> Not sure if we want to do the same. Two reasons.
>
> 1. Searching the netvsc source, I don't see a place that it set
> hv->vlan_strip to
> false. It means !hv->vlan_string is always false, and rte_vlan_insert(&m)
> never
> run.
It's set here:
drivers/net/netvsc/hn_ethdev.c: hv->vlan_strip = !
> +#define HN_VLAN_CFI_SHIFT12
> +#define HN_VLAN_PRI_SHIFT13
> +#define HN_VLAN_PRI_MASK 0xe000 /* Priority Code Point */
> +#define HN_VLAN_CFI_MASK 0x1000 /* Canonical Format Indicator / Drop
> Eligible Indicator */
> +#define HN_VLAN_VID_MASK 0x0fff /* VLAN Identifier */
> +
> + if (oob->rx_vlan_tag_present) {
> + mbuf->ol_flags |=
> + RTE_MBUF_F_RX_VLAN |
> RTE_MBUF_F_RX_VLAN_STRIPPED;
> + mbuf->vlan_tci = oob->rx_vlan_id;
> + }
> +
Netvsc has the following code for dealing wi
> -Original Message-
> From: Alan Elder
> Sent: Thursday, February 8, 2024 7:09 AM
> To: Long Li
> Cc: dev@dpdk.org
> Subject: [PATCH v3] net/netvsc: fix parsing of VLAN metadata
>
> The previous code incorrectly parsed the VLAN ID and priority.
> If
> > +struct ndis_pkt_vlan_info {
> > + union {
> > + struct {
> > + uint32_t pri:3; /* User
> > Priority */
> > + uint32_t cfi:1; /* Canonical
> > Format ID / DEI */
> >
> > On MR cache expension failure, the request should fail as there is no
> > path to get a new MR into the tree. Attempting to insert a new MR to
> > the cache tree will result in memory violation.
> >
>
> if this patch is fixing memory violation, can you please update commit log as
> fix
> comm
> > From: Long Li
> >
> > The content of the MR is copied to the cache trees, it's not necessary
> > to allocate a MR to do this. Use a variable on the stack instead.
> >
> > This also fixes the memory leak in the code where a MR is allocated
> >
> Hi Long,
>
> Assume that if "count > MANA_MBUF_BULK", and int the first iteration of the
> loop 'mana_post_rx_wqe()' failed, but in second iteration it is successful,
> this
> will cause function to return success in spite of failure in first iteration.
>
> As mbufs posted Rx queue, it may be
> > I think another approach is to use VLA by default, but for Windows use
> > alloc().
>
> a few thoughts on VLAs you may consider. not to be regarded as a strong
> objection.
>
> indications are that standard C will gradually phase out VLAs because they're
> generally accepted as having been
> I think default burst size 32 can be used like below:
>
> struct rte_mbuf *mbufs[32];
>
> loop: //use do {} while(); if you prefer n = min(32, count);
> rte_pktmbuf_alloc_bulk(mbufs, n); for (i = 0; i < n; i++)
> mana_post_rx_wqe(rxq, mbufs[i]);
> count -= n;
> if (count > 0) goto loop:
>
> > + /* Free the remaining mbufs that are not posted */
> > + while (i < count) {
> > + rte_pktmbuf_free(mbufs[i]);
> > + i++;
> > + }
>
> there is also rte_pktmbuf_free_bulk() that could be used. probably won't make
> any material difference to perf though so just an fy
> >> 'mbufs' is temporarily storage for allocated mbuf pointers, why not
> >> allocate if from stack instead, can be faster and easier to manage:
> >> "struct rte_mbuf *mbufs[count]"
> >
> > That would introduce a variable length array.
> > VLA's should be removed, they are not supported on Windows
> Subject: Re: [Patch v2] net/mana: use rte_pktmbuf_alloc_bulk for allocating RX
> WQEs
>
> On 1/30/2024 9:30 PM, Long Li wrote:
> >> Can you please quantify the performance improvement (as percentage),
> >> this clarifies the impact of the modification.
>
> Can you please quantify the performance improvement (as percentage), this
> clarifies the impact of the modification.
I didn't see any meaningful performance improvements in benchmarks. However,
this should improve CPU cycles and reduce potential locking conflicts in
real-world applications.
> Subject: Re: [PATCH] net/mana: use rte_pktmbuf_alloc_bulk for allocating RX
> WQEs
>
> On Wed, 24 Jan 2024 18:42:42 -0800
> lon...@linuxonhyperv.com wrote:
>
> > + struct rte_mbuf **mbufs;
> > +
> > + mbufs = rte_calloc("mana_rx_mbufs", count, sizeof(struct rte_mbuf *),
> > 0);
> > + if
> Subject: [PATCH v3 10/37] net/mana: replace RTE_LOG_DP with rte_log_dp
>
> Want datapath logs to use own logtype.
>
> Signed-off-by: Stephen Hemminger
Acked-by: Long Li
> ---
> drivers/net/mana/mana.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Subject: [PATCH v2 10/25] net/mana: replace RTE_LOG_DP with rte_log_dp
>
> Want datapath logs to use own logtype.
>
> Signed-off-by: Stephen Hemminger
Acked-by: Long Li
> ---
> drivers/net/mana/mana.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Subject: [PATCH 2/2] drivers: use function to compare PCI addresses
>
> Some places were not using the function rte_pci_addr_cmp() to compare 2 PCI
> addresses.
>
> Signed-off-by: Thomas Monjalon
For MANA,
Acked-by: Long Li
> ---
> drivers/net/mana/mana.c
existing rx and tx queue(s) are reconnected to the new vmbus channel(s).
>
> Signed-off-by: Sam Andrew
> Acked-by: Stephen Hemminger
Acked-by: Long Li
> ---
> v3: If device is not stopped when MTU change attempted, return -EBUSY, instead
> of -EIO. Fix additional coding st
use 64 bit doorbells.
> 64 bit applications can use 32 bit doorbells, however the performance would
> greatly suffer and it is not recommended.
>
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wei Hu
Acked-by: Long Li
a short doorbell support is needed to make mana fully functional for 32 bit
> applicatons.
>
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wei Hu
Acked-by: Long Li
> ---
> drivers/net/mana/mana.c | 2 +-
> drivers/net/mana/meson.build | 4 ++--
> drivers/net/mana/mr.c
> > Subject: RE: [PATCH 1/1] net/mana: add 32 bit short doorbell
> >
> > > > > +#ifdef RTE_ARCH_32
> > > > > + uint16_t cqe_incr =
> > > > > +(uint16_t)rxq->gdma_cq.head_incr_to_short_db;
> > > >
> > > > How do you make sure head_incr_to_short_db doesn't overflow?
> > > >
> > >
> > > I have che
> > > +#ifdef RTE_ARCH_32
> > > + uint16_t cqe_incr = (uint16_t)rxq->gdma_cq.head_incr_to_short_db;
> >
> > How do you make sure head_incr_to_short_db doesn't overflow?
> >
>
> I have checked this with hardware team. In my opinion it would be easily
> overflown.
> The hw team seems suggesting the
> Subject: [PATCH 1/1] net/mana: add 32 bit short doorbell
>
> Add 32 bit short doorbell support. Ring short doorbell when running in 32 bit
> applicactions.
>
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wei Hu
> ---
> drivers/net/mana/gdma.c | 95
> +
> dr
> Subject: [PATCH 1/1] net/mana: add 32 bit short doorbell
>
> Add 32 bit short doorbell support. Ring short doorbell when running in 32 bit
> applicactions.
>
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wei Hu
Please send this patch to
Ferruh Yigit
Andrew Rybchenko
> ---
> drivers/net/mana
in_popcountll; new=rte_popcount64;
> git grep -lw $old :^lib/eal/include/rte_bitops.h |
> xargs sed -i -e "s#\<$old\>#$new#g"
> $ old=__builtin_popcount; new=rte_popcount32;
> git grep -lw $old :^lib/eal/include/rte_bitops.h |
> xargs sed -i -e "s#\<$old\>#$new#g"
>
> Then inclusion of rte_bitops.h was added were necessary.
>
> Signed-off-by: David Marchand
Patch looks good for netvsc.
Reviewed-by: Long Li
ESS 0xC001000D
> #define RNDIS_STATUS_CLOSING_INDICATING 0xC001000E
> #define RNDIS_STATUS_INVALID_PACKET 0xC001000F
> --
> 2.39.2
Acked-by: Long Li
> Subject: Re: [PATCH] tap: fix build of tap_bpf_program
>
> On 7/20/2023 8:45 AM, Ferruh Yigit wrote:
> > On 7/19/2023 5:12 PM, Stephen Hemminger wrote:
> >> On Wed, 19 Jul 2023 11:03:36 +0100
> >> Ferruh Yigit wrote:
> >>
> >>> On 7/19/2023 11:00 AM, Ferruh Yigit wrote:
> On 7/17/2023 8:15
> Subject: Re: [PATCH] net/netvsc: set the correct queue state
>
> On Fri, 7 Jul 2023 11:53:16 -0700
> lon...@linuxonhyperv.com wrote:
>
> > From: Long Li
> >
> > Set the queue state when queue is started/stopped.
> >
> > Signed-off-by: Long Li
>
> Subject: Re: [PATCH] net/mana: fix wrong indexing on CQE error when coalescing
> is used
>
> On 7/7/2023 1:17 AM, lon...@linuxonhyperv.com wrote:
> > From: Long Li
> >
> > On a fatal CQE error when coalescing is used, update the correct index
> >
low/block scan mode
> > >
> > > Signed-off-by: Xiaoming Jiang
> >
> > Looks fine to me. Any comments from Long Li?
>
> Xiaoming, I have trouble applying the patch to the current vmbus code. Can
> you rebase the patch to the current next-net?
>
The patch can be merged.
Acked-by: Long Li
> Subject: Re: [PATCH] bus/vmbus: add support allow/block scan mode
>
> On Thu, 9 Jun 2022 08:46:18 +
> Xiaoming Jiang wrote:
>
> > bus/vmbus: add support allow/block scan mode
> >
> > Signed-off-by: Xiaoming Jiang
>
> Looks fine to me. Any c
>Subject: Re: [PATCH] net/mana: use RTE_LOG_DP for logs on datapath
>
>On 4/28/2023 2:29 AM, Long Li wrote:
>>
>>
>>> -Original Message-
>>> From: Ferruh Yigit
>>> Sent: Friday, March 3, 2023 5:15 PM
>>> To: Long Li ; Stephe
> -Original Message-
> From: Ferruh Yigit
> Sent: Friday, March 3, 2023 5:15 PM
> To: Long Li ; Stephen Hemminger
>
> Cc: lon...@linuxonhyperv.com; Thomas Monjalon ;
> Andrew Rybchenko ; Jerin Jacob
> Kollanukkaran ; David Marchand
> ; dev@dpdk.org; Ajay
> Subject: [PATCH 18/33] doc: update mana guide
>
> - Rename "MANA PMD arguments" section to "Runtime Configuration"
>
> Signed-off-by: Ferruh Yigit
Acked-by: Long Li
> ---
> doc/guides/nics/mana.rst | 4 ++--
> 1 file changed, 2 insertions(+),
> Subject: [PATCH 21/33] doc: update netvsc guide
>
> - Rename "Netvsc PMD arguments" section to "Runtime Configuration"
>
> Signed-off-by: Ferruh Yigit
Acked-by: Long Li
> ---
> doc/guides/nics/netvsc.rst | 4 ++--
> 1 file changed, 2 inserti
en parsed 'only keys'.
>
> This patch fixes segment fault when parse input args with 'only keys'.
>
> Fixes: a25d39a3eb69 ("net/netvsc: allow tuning latency with devargs")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Chengwen Feng
Thank you.
en parsed 'only keys'.
>
> This patch fixes segment fault when parse input args with 'only keys'.
>
> Fixes: 517ed6e2d590 ("net/mana: add basic driver with build environment")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Chengwen Feng
Acked-by: Long L
> Subject: Re: [Patch v10 01/18] net/mana: add basic driver with build
> environment and doc
>
> On 10/6/2022 12:21 AM, lon...@linuxonhyperv.com wrote:
> > diff --git a/doc/guides/nics/mana.rst b/doc/guides/nics/mana.rst new
> > file mode 100644 index 00..eeca153911
> > --- /dev/null
> > +
> Subject: Re: [PATCH 1/2] net/mana: avoid unnecessary assignments in data
> path
>
> On 3/17/2023 11:32 PM, lon...@linuxonhyperv.com wrote:
> > From: Long Li
> >
> > Unnecessary assignments involve memset and waste CPU cycles.
> > Removing them to reduce CP
> Subject: Re: [PATCH] net/mana: use RTE_LOG_DP for logs on datapath
>
> On 3/3/2023 2:16 AM, Long Li wrote:
> >> Subject: Re: [PATCH] net/mana: use RTE_LOG_DP for logs on datapath
> >>
> >> On Thu, 23 Feb 2023 10:09:17 -0800
> >> Stephen Hemminger w
> Subject: Re: [PATCH] net/mana: use RTE_LOG_DP for logs on datapath
>
> On Thu, 23 Feb 2023 10:09:17 -0800
> Stephen Hemminger wrote:
>
> > On Thu, 23 Feb 2023 14:07:25 +
> > Ferruh Yigit wrote:
> >
> > > Overall I am not sure if anyone is interested in driver datapath
> > > logs other tha
> Subject: Re: [PATCH 1/2] net/mana: add version information for dependencies
>
> On 1/20/2023 2:19 AM, lon...@linuxonhyperv.com wrote:
>
> > From: Long Li
> >
> > The required dependencies for mana from rdma-core and Linux kernel
> > have been releas
for development and investigation.
> > >
> > > When all dependencies are upstreamed, driver can be enabled back.
> > >
> > > Fixes: 517ed6e2d590 ("net/mana: add basic driver with build
> > > environment")
> > >
> > > Signed-off-by: Ferr
ixes: 517ed6e2d590 ("net/mana: add basic driver with build environment")
>
> Signed-off-by: Ferruh Yigit
Acked-by: Long Li
> ---
> Cc: Long Li
> Cc: Stephen Hemminger
> ---
> MAINTAINERS| 2 +-
> doc/guides/nics/index.rst
> Subject: Re: [PATCH] net/mana: fix dependencies
>
> 10/10/2022 20:53, Long Li:
> > I will send respin as soon as patch submission window reopens.
>
> So what do we do in DPDK?
> Do you agree with the patch I sent to correct wrong assumptions in the doc?
Yes, th
I will send respin as soon as patch submission window reopens.
Thanks,
Long
From: Jason Gunthorpe
Sent: Sunday, October 9, 2022 7:08 AM
To: thomas ; Long Li
Cc: dev@dpdk.org; ferruh.yi...@amd.com; andrew.rybche...@oktetlabs.ru;
step...@networkplumber.org
Subject: Re: [PATCH] net/mana: fix
> Subject: Re: [Patch v10 00/18] Introduce Microsoft Azure Network Adatper
> (MANA) PMD
>
> On 10/6/2022 9:54 AM, Ferruh Yigit wrote:
> > On 10/6/2022 12:21 AM, lon...@linuxonhyperv.com wrote:
> >
> >>
> >> From: Long Li
> >>
> >> MA
> Subject: Re: [Patch v9 00/18] Introduce Microsoft Azure Network Adatper
> (MANA) PMD
>
> On 9/24/2022 3:45 AM, lon...@linuxonhyperv.com wrote:
>
> >
> > From: Long Li
> >
> > MANA is a network interface card to be used in the Azure cloud
> environm
> Subject: Re: [Patch v8 01/18] net/mana: add basic driver with build
> environment and doc
>
> On 9/8/2022 10:56 PM, lon...@linuxonhyperv.com wrote:
> > From: Long Li
> >
> > MANA is a PCI device. It uses IB verbs to access hardware through the
> > kernel RDM
> Subject: Re: [Patch v8 01/18] net/mana: add basic driver with build
> environment and doc
>
> On 9/8/2022 10:56 PM, lon...@linuxonhyperv.com wrote:
> > From: Long Li
> >
> > MANA is a PCI device. It uses IB verbs to access hardware through the
> > kernel RDM
> Subject: Re: [Patch v7 18/18] net/mana: add function to support RX
> interrupts
>
> On 9/3/2022 2:41 AM, lon...@linuxonhyperv.com wrote:
>
> >
> > From: Long Li
> >
> > mana can receive RX interrupts from kernel through RDMA verbs interface.
&g
> Subject: Re: [Patch v7 11/18] net/mana: implement the hardware layer
> operations
>
> On 9/3/2022 2:40 AM, lon...@linuxonhyperv.com wrote:
>
> >
> > From: Long Li
> >
> > The hardware layer of MANA understands the device queue and doorbell
> > for
s, clicking links, or
> responding to this email.
> >
> >
> > From: Long Li
> >
> > MANA is a PCI device. It uses IB verbs to access hardware through the
> > kernel RDMA layer. This patch introduces build environment and basic
> > device probe functio
> Subject: Re: [Patch v7 01/18] net/mana: add basic driver, build environment
> and doc
>
> On 9/7/2022 3:41 AM, Long Li wrote:
>
> >
> >> Subject: RE: [Patch v7 01/18] net/mana: add basic driver, build
> >> environment and doc
> >>
> >>&
, clicking
> > links, or responding to this email.
> >
> >
> > 在 2022/9/7 9:36, Long Li 写道:
> >>> Subject: Re: [Patch v6 01/18] net/mana: add basic driver, build
> >>> environment and doc
> >>>
> >>>
> >>> 在 2022/9/1 2:05,
> Subject: RE: [Patch v7 01/18] net/mana: add basic driver, build environment
> and doc
>
> > Subject: Re: [Patch v7 01/18] net/mana: add basic driver, build
> > environment and doc
> >
> > On 9/3/2022 2:40 AM, lon...@linuxonhyperv.com wrote:
> >
> >
1 - 100 of 188 matches
Mail list logo
