ote:
>
> > > -Original Message-
> > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of jigsaw
> > > Sent: Thursday, April 13, 2017 9:59 PM
> > > To: Adrien Mazarguil
> > > Cc: dev@dpdk.org
> > > Subject: Re: [dpdk-dev] Proposal
PM, Adrien Mazarguil <
adrien.mazarg...@6wind.com> wrote:
> Hi Qinglai,
>
> On Thu, Apr 13, 2017 at 04:38:19PM +0300, jigsaw wrote:
> > Hi,
> >
> > I have a proposal for mbuf race condition detection and I would like to
> get
> > your opinions before
>
Hi,
I have a proposal for mbuf race condition detection and I would like to get
your opinions before
committing any patch.
Race condition is the worst bug I can think of; as it causes crashing long
after the first crime scene,
and the consequence is unpredictable and difficult to understand.
Bes
locking model,
which favors one lock-owner core. But unfortunately the biased locking
model doesn't seem to be applicable for distributor.
thx &
rgds,
-ql
On Wed, Nov 12, 2014 at 7:11 PM, jigsaw wrote:
> Hi Bruce,
>
> Thanks for your reply.
>
> I agree that to logicall
OK thanks. Sorry my bad. -ql
On Thu, Nov 13, 2014 at 11:18 AM, Thomas Monjalon wrote:
> 2014-11-13 08:56, jigsaw:
> > >>Do you have another commit before this one in your tree?
> >
> > Yes this patch relies on this one:
> > http://dpdk.org/ml/archives/dev/2014-N
Hi Thomas,
>>Do you have another commit before this one in your tree?
Yes this patch relies on this one:
http://dpdk.org/ml/archives/dev/2014-November/007943.html
Sorry I didn't make it clear. The new field usr in rte_mbuf was under same
cover letter in v2 of the in_flight_bitmask patch.
Then in
uce Richardson <
bruce.richardson at intel.com> wrote:
> On Wed, Nov 12, 2014 at 10:37:33AM +0200, jigsaw wrote:
> > Hi,
> >
> > OK it is now very clear it is due to memory transactions between
> different
> > nodes.
> >
> > The test program is here:
> >
at 5:37 PM, jigsaw wrote:
> Hi Bruce,
>
> I noticed that librte_distributor has quite sever LLC miss problem when
> running on 16 cores.
> While on 8 cores, there's no such problem.
> The test runs on a Intel(R) Xeon(R) CPU E5-2670, a SandyBridge with 32
> cores on 2 soc
Hi Bruce,
I noticed that librte_distributor has quite sever LLC miss problem when
running on 16 cores.
While on 8 cores, there's no such problem.
The test runs on a Intel(R) Xeon(R) CPU E5-2670, a SandyBridge with 32
cores on 2 sockets.
The test case is the distributor_perf_autotest, i.e.
in app/
bitmask is not in the hot path, and
is irrelevant to the performance of distributor.
Thanks a lot for your code review and ack.
thx &
rgds,
-qinglai
On Mon, Nov 10, 2014 at 6:55 PM, Bruce Richardson <
bruce.richardson at intel.com> wrote:
> On Mon, Nov 10, 2014 at 05:52:
Hi Bruce,
Sorry I didn't. I will run a performance test tomorrow.
thx &
rgds,
-qinglai
On Mon, Nov 10, 2014 at 5:13 PM, Bruce Richardson <
bruce.richardson at intel.com> wrote:
> On Mon, Nov 10, 2014 at 04:44:02PM +0200, Qinglai Xiao wrote:
> > With introduction of in_flight_bitmask, the whole
OK thx Bruce, I will make 2 commits with one cover-letter.
On Mon, Nov 10, 2014 at 1:09 PM, Bruce Richardson <
bruce.richardson at intel.com> wrote:
> On Mon, Nov 10, 2014 at 12:38:32PM +0200, Qinglai Xiao wrote:
> > User application is advocated to set the newly introduced union field
> > mbuf->
OK thanks Bruce. I will get the patch done in coming week. -qinglai
On Fri, Nov 7, 2014 at 5:04 PM, Bruce Richardson wrote:
> On Fri, Nov 07, 2014 at 04:52:46PM +0200, jigsaw wrote:
> > Yeah that's better. As below, right?
>
> Yep.
>
> >
> > @@ -290,6 +294,
>in_flight_bitmask;
if (match) {
next_mb = NULL;
unsigned worker = __builtin_ctz(match);
On Fri, Nov 7, 2014 at 4:44 PM, Bruce Richardson wrote:
> On Fri, Nov 07, 2014 at 04:31:18PM +0200, jigsaw wrote:
> >
Hi Thomas,
Thanks for the reminder. I didn't notice the change in comments yet.
thx &
rgds,
-qinglai
On Fri, Nov 7, 2014 at 4:08 PM, Thomas Monjalon
wrote:
> 2014-11-06 13:55, Bruce Richardson:
> > From: "Bruce Richardson"
> >
> > Add in some additional comments around more complex areas of t
E_DISTRIB_FLAG_BITS;
On Fri, Nov 7, 2014 at 3:53 PM, Bruce Richardson wrote:
> On Fri, Nov 07, 2014 at 02:38:13PM +0200, jigsaw wrote:
> > Hi Bruce,
> >
> > >> If a tag value of zero is ever passed in, then it will start matching
> > against cores which are no
er app.
This is just another trade-off. Since I am in need of such freedom, I am
more interested in the free use of 32bits.
thx &
rgds,
-qinglai
On Fri, Nov 7, 2014 at 11:45 AM, Bruce Richardson <
bruce.richardson at intel.com> wrote:
> On Thu, Nov 06, 2014 at 09:52:25PM +020
rgds,
-qinglai
On Thu, Nov 6, 2014 at 8:01 PM, jigsaw wrote:
> Hi Bruce,
>
> In my use case, unfortunately the tag is not hash. And the tag can be on
> either low or high bits, depending on configuration.
> I wonder if it is possible to let the user to decide which bit to mask,
> i.e. t
butor just
> uses a
> 31-bit tag rather than a 32-bit one.
>
> /Bruce
>
> >
> > thx &
> > rgds
> > -qinglai
> >
> > --
> > ???: "Thomas Monjalon"
> > : ?2014/?11/?6 12:36
> > ???: "Bruce Richards
OK understood. Thanks. -qinglai
On Thu, Nov 6, 2014 at 11:22 AM, Bruce Richardson <
bruce.richardson at intel.com> wrote:
> On Wed, Nov 05, 2014 at 07:24:13PM +0200, jigsaw wrote:
> > Hi Bruce,
> >
> > OK understood. Then there's no real need to make any chan
-qinglai
On Wed, Nov 5, 2014 at 6:36 PM, Bruce Richardson wrote:
> On Wed, Nov 05, 2014 at 05:11:51PM +0200, jigsaw wrote:
> > Hi Bruce,
> >
> > Thanks for reply.
> > The idea is triggered by real life use case, where the flow id is buried
> in
> > L3 payload
Hi Konstantin,
I agree with you. A callback is not necessary. Pls refer to my previous
mail, which proposed a not-at-all-intrusive patch.
Pls let me know your concern.
thx &
rgds,
-qinglai
On Wed, Nov 5, 2014 at 5:13 PM, Ananyev, Konstantin <
konstantin.ananyev at intel.com> wrote:
>
>
> >
Hi Bruce,
Thanks for reply.
The idea is triggered by real life use case, where the flow id is buried in
L3 payload. Deep packet inspection is one of the scenarios, tunneled pkts
is another.
However, only functionality is verified. Performance impact has not been
checked yet.
To add distributor an
Hi Stephen,
Have you tried link time optimization on DPDK application? Does it
decrease the I-cache miss rate evidently?
thx &
rgds,
-Qinglai
On Sun, Feb 16, 2014 at 9:02 PM, Stephen Hemminger
wrote:
> On Fri, 14 Feb 2014 15:11:29 -0500
> Ymo Lists wrote:
>
>> "Enqueuing and dequeuing items fr
http://dpdk.org/ml/archives/dev/2014-January/001205.html
Likely to be the root cause. It needs a patch coz it caused problems
now and then without giving noticeable reason in the log.
-Qinglai
On Fri, Feb 14, 2014 at 11:30 AM, Prashant Upadhyaya
wrote:
> Pasting the logs inline as the attachmen
actually have two virtual functions and two physical functions, but
> I just repeat above for each.
>
> Regards
> Mats
>
> On Tue, Feb 4, 2014 at 12:14 PM, jigsaw wrote:
>> Hi Mats,
>>
>> I didn't have any deviation. What I did is just loading ixgbe (with
&
packets was placed in the transmit queue, but these packets was
> never sent.
>
> I'll see if I can get this working without loading ixgbevf in the host.
>
> What instructions did you follow to get this working? Did you do any
> deviation from the instructions?
>
> Reg
Hi Mats,
I've tried vf with 82599EB and it works fine. As long as the VF is
visible in guest, DPDK's VF driver should work just as ixgbevf, which
shares more or less the same code.
I don't understand why you would expect DPDK at guest to work as VF,
while the host has no ixgbe loaded.
To make fur
I had exactly same problem and fixed it with same patch since release
1.4. But somehow it stopped to appear even without the patch. I have
no idea what I have done since both the kernel and the driver have
been updated during these days.
On Wed, Nov 27, 2013 at 4:06 PM, Dmitry Vyal wrote:
> Looks
On Thu, Oct 24, 2013 at 11:48 AM, Thomas Monjalon
wrote:
> 23/10/2013 14:26, jigsaw :
>> First of all, where and how should I post the patch to PF driver?
>
> You should send your patch to kernel.org via the netdev mailing list:
> http://vger.kernel.org/vger-lists.html#netd
Hi Thomas,
>>Please, keep us informed about the needed PF patch.
First of all, where and how should I post the patch to PF driver?
And secondly I have only 82599, so I cannot run test for 82598 and
X540. Is it possible that you could test on different NIC?
thx &
rgds,
-ql
On Wed, Oct 23, 2013 a
Sorry it was not on my mind. Next patch will not have any trace to GPL code. -ql
On Mon, Oct 21, 2013 at 4:04 PM, Thomas Monjalon
wrote:
> 21/10/2013 13:28, jigsaw :
>> The ixgbevf_negotiate_api is copied from Intel's VF driver.
> [..]
>> I will make another atte
Hi Thomas,
Thanks for comment.
The ixgbevf_negotiate_api is copied from Intel's VF driver. The while
loop is not quite usual, indeed. A direct call to
ixgbevf_negotiate_api_version(hw, ixgbe_mbox_api_11) is sufficient, I
think. Coz PF is supposed to be satisfied with ver 1.1.
I will make another a
Oct 17, 2013 at 4:47 PM, Thomas Monjalon
wrote:
> 17/10/2013 14:43, jigsaw :
>> I patched both Intel ixgbe PF driver and DPDK 1.5 VF driver, so that
>> DPDK gets 4 queues in one VF. It works fine with all 4 Tx queues. The
>> only trick is to set proper mac address for all outgoin
was courtesy your mail that I 'discovered' that DPDK has such a
> limitation.
>
> So I am all for this patch to go in DPDK. Good luck !
>
> Regards
> -Prashant
>
>
> -Original Message-
> From: jigsaw [mailto:jigsaw at gmail.com]
> Sent: Thursday, Octobe
thx &
rgds,
-ql
On Thu, Oct 17, 2013 at 3:43 PM, jigsaw wrote:
> Hi Prashant,
>
> I patched both Intel ixgbe PF driver and DPDK 1.5 VF driver, so that
> DPDK gets 4 queues in one VF. It works fine with all 4 Tx queues. The
> only trick is to set proper mac address for all outgoi
host. The guest would
> communicate with the PF on host using mailbox as usual.
> Then the changes will be limited to DPDK, isn't it ?
>
> Regards
> -Prashant
>
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of jigsaw
> Sent:
. The driver on sf.net is a read-only repository, isn't it? It
would be painful to maintain another branch of 10G PF driver.
Could Intel give some advice or hints here?
thx &
rgds,
-Qinglai
On Wed, Oct 16, 2013 at 3:58 PM, Thomas Monjalon
wrote:
> 16/10/2013 14:18, jigsaw :
>&
Hi,
I am doing experiments with SR-IOV + passthrough on 82599.
My expectation is to have VT on and DCB off, under which
configuration, the total 128 TX queues will be split into 32 pools,
each has 4 queues.
With latest driver ixgbe-3.18.7, PF can be set with 16 pools, each has
4 queues with these
PKT_RX_IP_CKSUM_BAD) != 0);
> rx_bad_l4_csum += (uint16_t) ((pkt_ol_flags &
> PKT_RX_L4_CKSUM_BAD) != 0);
>
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of jigsaw
> Sent: Saturday, October 05, 2013 3:11 AM
> To: Venkates
--
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger
> Sent: Friday, October 04, 2013 11:23 AM
> To: jigsaw
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] Request for comments on ixgbe TSO support
>
> On Fri, 4 Oct 2013 20:54:31 +0300
> jigs
Hi Stephen,
>>This will work for local generated packets but overlapping existing field
>>won't work well for forwarding.
So adding a new mss field in mbuf could be the way out? or I
misunderstand something.
>> What we want to be able to do is to take offload (jumbo) packets in with
>> from vi
Hi Stephen,
Thanks for comment. Pls check the other thread that I just posted.
thx &
rgds,
-Qinglai
On Fri, Oct 4, 2013 at 7:41 PM, Stephen Hemminger
wrote:
> On Fri, 4 Oct 2013 15:44:19 +0300
> jigsaw wrote:
>
>> Hi,
>>
>> I'm working on TSO for 82599,
Hi,
I'm working on TSO for 82599, and encounter a problem: nowhere to store MSS.
TSO must be aware of MSS, or gso in skb of kernel.
But MSS nees 16 bits per mbuf. And we have no spare 16 bits in
rte_mbuf or rte_pktmbuf.
If we add 16 bit field in rte_pktmbuf, the size of rte_mbuf will be
doubled,
t() [ open to suggestions ].
>
> Regards,
> -Venky
>
> -Original Message-
> From: jigsaw [mailto:jigsaw at gmail.com]
> Sent: Wednesday, September 25, 2013 7:39 AM
> To: Venkatesan, Venky
> Cc: Ivan Boule; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] Add suppo
Hi Thomas,
The patch can be made without modifying ixgbe/ at all, I will make
another attempt. Please see the proposal in my previous email.
The question is how to keep the lpbk_mode field in struct rte_eth_conf
future-proof. Or if this is overkill to think about possible future
loopback support a
ectly from the
> BSD driver baseline, and any changes will make future merges of newer code
> more challenging. The changes should be limited to files in the
> librte_pmd_ixgbe directory (and ethdev).
>
> Regards,
> -Venky
>
>
> -Original Message-
> Fr
Hi Ivan,
Appreciations for your comments.
I have one question regarding the new field, lpbk_mode, in struct rte_eth_conf.
I was thinking how to define the values for this field, then I had a dilemma.
82599 has only two mode of loopback, either Tx->Rx or Rx->Tx.
But other controller may have diff
top of
it.
https://gist.github.com/jigsawecho/6671630
On Mon, Sep 23, 2013 at 11:42 AM, Thomas Monjalon wrote:
> Hello,
>
> 22/09/2013 20:01, jigsaw :
> > Is there any plan for adding support for 82599 features such as:
> >
> > 1. Loopback operation for diagnostic purpo
Hi,
Is there any plan for adding support for 82599 features such as:
1. Loopback operation for diagnostic purpose
The Tx->Rx loopback operation is handy when debugging with a standalone 10G
port.
2. TCP/UDP segmentation in Tx (TSE bit in DCMD)
TSO implementation is already in kernel. Is it in
50 matches
Mail list logo
