DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ivan Boule <ivan.boule@6wind.com>
To: santosh <santosh.iitg@gmail.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] ixgbe : query regarding your code changes for VF mac add
Date: Wed, 20 Apr 2016 09:31:30 +0200	[thread overview]
Message-ID: <CAOm6c7ppjBaCnTG7EZfGOdKnEe4MHAdvwFOPxCVbz-rh7enP5w@mail.gmail.com> (raw)
In-Reply-To: <CADUNanjr64fOwx71acne4s3f8HDC5G7BjvaW2RLEAnGsLMcG-w@mail.gmail.com>

Hi Santosh,

I do not get exactly what you attempt to do on a VF.
Are you first deleting the so-called permanent MAC address by a call to the
function ixgbevf_remove_mac_addr() ? This operation is not allowed.
Can you explain exactly the sequence of operations that are done, so that I
can understand how the test (memcmp(hw->mac.perm_addr, mac_addr,
sizeof(struct ether_addr)) == 0) in the function ixgbevf_add_mac_addr()
prevents them to be successfully performed.

Ivan

PS : please, can you CC your emails to dev@dpdk.org


2016-04-19 17:01 GMT+02:00 santosh <santosh.iitg@gmail.com>:

> Hi Ivan,
>
> Your following code changes causing issue in Vmware environment.
>
> ----------------------------------- -------------------
> ------------------------------
> + /*
> + * On a 82599 VF, adding again the same MAC addr is not an idempotent
> + * operation. Trap this case to avoid exhausting the [very limited]
> + * set of PF resources used to store VF MAC addresses.
> + */
> + if (memcmp(hw->mac.perm_addr, mac_addr, sizeof(struct ether_addr)) == 0)
> + return;
>   diag = ixgbevf_set_uc_addr_vf(hw, 2, mac_addr->addr_bytes);
> --------------------------------------------------------------------
> ------------- -------
>
>
> Issue:
> At CLI , we have provision to add /del MAC of an interface.
> During MAC delete, existing MAC is deleted and default MAC is applied.
> This default MAC is not being applied in VMware environment
> successfully due to "return" statement
> in your above code changes. As a result traffic is stopped completely.
> If I remove above
> "return" statement then traffic continues to flow after MAC delete.
>
> Please let me know your suggestion to handle this scenario .  If I
> remove "return" what will be the consequences ?
>
> If removing "return" statement is not good idea then what are other
> way to handle MAC delete scenario ?  we have only 1 VF per PF in our
> setup as of now.
>
>
> Thanks
> Santosh
>



-- 
Ivan BOULE
6WIND
Software Engineer

Tel: +33 1 39 30 92 47
Mob: + 33 6 77 25 26 38
Fax: +33 1 39 30 92 11
ivan.boule@6wind.com
www.6wind.com
Join the Multicore Packet Processing Forum:
www.multicorepacketprocessing.com

Ce courriel ainsi que toutes les pièces jointes, est uniquement destiné à
son ou ses destinataires. Il contient des informations confidentielles qui
sont la propriété de 6WIND. Toute révélation, distribution ou copie des
informations qu'il contient est strictement interdite. Si vous avez reçu ce
message par erreur, veuillez immédiatement le signaler à l'émetteur et
détruire toutes les données reçues.

This e-mail message, including any attachments, is for the sole use of the
intended recipient(s) and contains information that is confidential and
proprietary to 6WIND. All unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.

       reply	other threads:[~2016-04-20  7:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CADUNanjr64fOwx71acne4s3f8HDC5G7BjvaW2RLEAnGsLMcG-w@mail.gmail.com>
2016-04-20  7:31 ` Ivan Boule [this message]
2016-04-20  9:05   ` santosh
2016-04-21  5:55     ` santosh
2016-04-22  7:21       ` Ivan Boule
2016-04-25 13:35         ` santosh
2016-04-26  5:36           ` santosh
2016-04-26  9:12             ` Ivan Boule
2016-04-22  7:17     ` Ivan Boule

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=CAOm6c7ppjBaCnTG7EZfGOdKnEe4MHAdvwFOPxCVbz-rh7enP5w@mail.gmail.com \
    --to=ivan.boule@6wind.com \
    --cc=dev@dpdk.org \
    --cc=santosh.iitg@gmail.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).