> > I am inclined to use option 2 to have per-pmd cmap of bonds however,
> > I see that even in this option we will need to have one cmap (or hmap)
> > of bonds at global datapath level. This will take care of
> > reconfigure_pmd_threads
> > scenario. New PMDs needs to be configured with bond cmap
On 2/6/20 7:39 AM, Vishal Deep Ajmera wrote:
>>>
>>> So, the root cause of all the issues in this patch, in my understanding,
>>> is the fact that you need to collect statistics for all the bond hashes
>>> in order to be able to rebalance traffic. This forces you to have access
>>> to PMD local
> >
> > So, the root cause of all the issues in this patch, in my understanding,
> > is the fact that you need to collect statistics for all the bond hashes
> > in order to be able to rebalance traffic. This forces you to have access
> > to PMD local caches.
> >
> > The basic idea how to overcome
>
> So, the root cause of all the issues in this patch, in my understanding,
> is the fact that you need to collect statistics for all the bond hashes
> in order to be able to rebalance traffic. This forces you to have access
> to PMD local caches.
>
> The basic idea how to overcome this issue is
On 20.01.2020 17:09, Ilya Maximets wrote:
> On 08.01.2020 06:18, Vishal Deep Ajmera wrote:
>> Problem:
>>
>> In OVS-DPDK, flows with output over a bond interface of type “balance-tcp”
>> (using a hash on TCP/UDP 5-tuple) get translated by the ofproto layer into
>> "HASH" and "RECIRC"
On 21.01.2020 21:54, Ben Pfaff wrote:
> On Mon, Jan 20, 2020 at 05:09:05PM +0100, Ilya Maximets wrote:
>>> +static struct tx_bond *
>>> +tx_bond_lookup(const struct hmap *hmap, uint32_t bond_id)
>>> +{
>>> +struct tx_bond *tx;
>>> +
>>> +HMAP_FOR_EACH_IN_BUCKET (tx, node,
On Mon, Jan 20, 2020 at 05:09:05PM +0100, Ilya Maximets wrote:
> > +static struct tx_bond *
> > +tx_bond_lookup(const struct hmap *hmap, uint32_t bond_id)
> > +{
> > +struct tx_bond *tx;
> > +
> > +HMAP_FOR_EACH_IN_BUCKET (tx, node, hash_bond_id(bond_id), hmap) {
>
> Why not
On 08.01.2020 06:18, Vishal Deep Ajmera wrote:
> Problem:
>
> In OVS-DPDK, flows with output over a bond interface of type “balance-tcp”
> (using a hash on TCP/UDP 5-tuple) get translated by the ofproto layer into
> "HASH" and "RECIRC" datapath actions. After recirculation, the packet is
> >
> > Thanks for the patch!
> >
> > I have a few minor stylistic suggestions, see below.
> >
> > I'd like to hear Ilya's opinion on this.
>
> Thanks Ben for review! I'll take another look at this patch in a next
> couple of days.
>
> >
Hi Ilya, Ben,
Let me know if you have any comments. Can
On 20.01.2020 10:00, Vishal Deep Ajmera wrote:
>>>
>>> Thanks for the patch!
>>>
>>> I have a few minor stylistic suggestions, see below.
>>>
>>> I'd like to hear Ilya's opinion on this.
>>
>> Thanks Ben for review! I'll take another look at this patch in a next
>> couple of days.
>>
>>>
>
> Hi
On 08.01.2020 21:33, Ben Pfaff wrote:
> On Wed, Jan 08, 2020 at 10:48:04AM +0530, Vishal Deep Ajmera wrote:
>> Problem:
>>
>> In OVS-DPDK, flows with output over a bond interface of type “balance-tcp”
>> (using a hash on TCP/UDP 5-tuple) get translated by the ofproto layer into
>> "HASH"
On Wed, Jan 08, 2020 at 10:48:04AM +0530, Vishal Deep Ajmera wrote:
> Problem:
>
> In OVS-DPDK, flows with output over a bond interface of type “balance-tcp”
> (using a hash on TCP/UDP 5-tuple) get translated by the ofproto layer into
> "HASH" and "RECIRC" datapath actions. After
Problem:
In OVS-DPDK, flows with output over a bond interface of type “balance-tcp”
(using a hash on TCP/UDP 5-tuple) get translated by the ofproto layer into
"HASH" and "RECIRC" datapath actions. After recirculation, the packet is
forwarded to the bond member port based on 8-bits of the
13 matches
Mail list logo
