From: "Qiu, Michael" <michael.qiu@intel.com>
To: "Wu, Jingjing" <jingjing.wu@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 2/2] i40e: enable internal switch of pf
Date: Thu, 29 Jan 2015 06:52:45 +0000 [thread overview]
Message-ID: <533710CFB86FA344BFBF2D6802E60286CCFC84@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <9BB6961774997848B5B42BEC655768F8B86F0A@SHSMSX104.ccr.corp.intel.com>
On 1/29/2015 2:27 PM, Wu, Jingjing wrote:
> Hi, Michael
>
>> -----Original Message-----
>> From: Qiu, Michael
>> Sent: Thursday, January 29, 2015 2:06 PM
>> To: Wu, Jingjing; dev@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH 2/2] i40e: enable internal switch of pf
>>
>> On 1/29/2015 12:57 PM, Wu, Jingjing wrote:
>>> Hi, Michael
>>>
>>>> -----Original Message-----
>>>> From: Qiu, Michael
>>>> Sent: Thursday, January 29, 2015 9:56 AM
>>>> To: Wu, Jingjing; dev@dpdk.org
>>>> Subject: Re: [dpdk-dev] [PATCH 2/2] i40e: enable internal switch of
>>>> pf
>>>>
>>>> On 1/29/2015 9:42 AM, Jingjing Wu wrote:
>>>>> This patch enables PF's internal switch by setting ALLOWLOOPBACK
>>>>> flag when VEB is created. With this patch, traffic from PF can be
>>>>> switched on the VEB.
>>>>>
>>>>> Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
>>>>> ---
>>>>> lib/librte_pmd_i40e/i40e_ethdev.c | 36
>>>>> ++++++++++++++++++++++++++++++++++++
>>>>> 1 file changed, 36 insertions(+)
>>>>>
>>>>> diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c
>>>>> b/lib/librte_pmd_i40e/i40e_ethdev.c
>>>>> index fe758c2..94fd36c 100644
>>>>> --- a/lib/librte_pmd_i40e/i40e_ethdev.c
>>>>> +++ b/lib/librte_pmd_i40e/i40e_ethdev.c
>>>>> @@ -2854,6 +2854,40 @@ i40e_vsi_dump_bw_config(struct i40e_vsi
>> *vsi)
>>>>> return 0;
>>>>> }
>>>>>
>>>>> +/*
>>>>> + * i40e_enable_pf_lb
>>>>> + * @pf: pointer to the pf structure
>>>>> + *
>>>>> + * allow loopback on pf
>>>>> + */
>>>>> +static inline void
>>>>> +i40e_enable_pf_lb(struct i40e_pf *pf) {
>>>>> + struct i40e_hw *hw = I40E_PF_TO_HW(pf);
>>>>> + struct i40e_vsi_context ctxt;
>>>>> + int ret;
>>>>> +
>>>>> + memset(&ctxt, 0, sizeof(ctxt));
>>>>> + ctxt.seid = pf->main_vsi_seid;
>>>>> + ctxt.pf_num = hw->pf_id;
>>>>> + ret = i40e_aq_get_vsi_params(hw, &ctxt, NULL);
>>>>> + if (ret) {
>>>>> + PMD_DRV_LOG(ERR, "couldn't get pf vsi config, err %d,
>>>> aq_err %d",
>>>>> + ret, hw->aq.asq_last_status);
>>>>> + return;
>>>>> + }
>>>>> + ctxt.flags = I40E_AQ_VSI_TYPE_PF;
>>>>> + ctxt.info.valid_sections =
>>>>> + rte_cpu_to_le_16(I40E_AQ_VSI_PROP_SWITCH_VALID);
>>>> Here does it need to be "|=" ? As ctxt.infowill be filled in
>>>> i40e_aq_get_vsi_params(), I don't know if it has other issue for
>>>> override this filled by "=".
>>>>
>>>> Thanks,
>>>> Michael
>>> You can look at the following lines. What we called is
>> i40e_aq_update_vsi_params.
>>> So we need only set the flag we want to update.
>> Sorry, I make a mistake, what I mean is:
>>
>> 1. ret = i40e_aq_get_vsi_params(hw, &ctxt, NULL);
>> here will fill the the field ctxt.info of struct i40e_vsi_context ctxt right?
>> So ctxt.info is get from other place.
>>
>> 2. Then:
>>
>> + ctxt.info.valid_sections =
>> + rte_cpu_to_le_16(I40E_AQ_VSI_PROP_SWITCH_VALID);
>>
>> Has been override by assignment a value, so I just confuse whether it has
>> some issue.
>>
>> If I'm wrong, please ignore.
>>
>>
>> Thanks,
>> Michael
>>
> I get your idea now. Some elements in ctxt is meaningless and not set when getting, and others are meaningful when
> updating. The valid_sections is only meaningful when setting. If one flag in valid_section is set, it means the
> hw need to process corresponding section.
OK, as it meaningless, I agree with you.
Thanks,
Michael
>>> Thanks
>>> Jingjing
>>>
>>>>> + ctxt.info.switch_id |=
>>>>> + rte_cpu_to_le_16(I40E_AQ_VSI_SW_ID_FLAG_ALLOW_LB);
>>>>> +
>>>>> + ret = i40e_aq_update_vsi_params(hw, &ctxt, NULL);
>>>>> + if (ret)
>>>>> + PMD_DRV_LOG(ERR, "update vsi switch failed,
>>>> aq_err=%d\n",
>>>>> + hw->aq.asq_last_status);
>>>>> +}
>>>>> +
>>>>> /* Setup a VSI */
>>>>> struct i40e_vsi *
>>>>> i40e_vsi_setup(struct i40e_pf *pf,
>>>>> @@ -2889,6 +2923,8 @@ i40e_vsi_setup(struct i40e_pf *pf,
>>>>> PMD_DRV_LOG(ERR, "VEB setup failed");
>>>>> return NULL;
>>>>> }
>>>>> + /* set ALLOWLOOPBACk on pf, when veb is created */
>>>>> + i40e_enable_pf_lb(pf);
>>>>> }
>>>>>
>>>>> vsi = rte_zmalloc("i40e_vsi", sizeof(struct i40e_vsi), 0);
>
next prev parent reply other threads:[~2015-01-29 6:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-29 1:41 [dpdk-dev] [PATCH 0/2] enable SRIOV switch in i40e driver Jingjing Wu
2015-01-29 1:41 ` [dpdk-dev] [PATCH 1/2] i40e: fix the bug when configuring vsi Jingjing Wu
2015-01-29 1:41 ` [dpdk-dev] [PATCH 2/2] i40e: enable internal switch of pf Jingjing Wu
2015-01-29 1:56 ` Qiu, Michael
2015-01-29 4:57 ` Wu, Jingjing
2015-01-29 6:06 ` Qiu, Michael
2015-01-29 6:26 ` Wu, Jingjing
2015-01-29 6:52 ` Qiu, Michael [this message]
2015-02-04 7:41 ` [dpdk-dev] [PATCH 0/2] enable SRIOV switch in i40e driver Liu, Jijiang
2015-02-09 8:55 ` Zhang, Helin
2015-02-15 6:26 ` Cao, Min
2015-02-15 6:30 ` Cao, Min
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=533710CFB86FA344BFBF2D6802E60286CCFC84@SHSMSX101.ccr.corp.intel.com \
--to=michael.qiu@intel.com \
--cc=dev@dpdk.org \
--cc=jingjing.wu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).