On 2019-06-14 20:15, Maciej Fijalkowski wrote:
> On Fri, 14 Jun 2019 13:25:24 +
> Maxim Mikityanskiy wrote:
>
>> On 2019-06-13 17:45, Maciej Fijalkowski wrote:
>>> On Thu, 13 Jun 2019 14:01:39 +
>>> Maxim Mikityanskiy wrote:
>>>
On 2019-06-12 23:23, Jakub Kicinski wrote:
> O
On Fri, 14 Jun 2019 13:25:05 +, Maxim Mikityanskiy wrote:
> Imagine you have configured the NIC to have the maximum supported amount
> of channels. Then your formula in ethtool.c returns some value. Exactly
> the same value should also be returned from libbpf's
> xsk_get_max_queues(). It's a
On 2019-06-14 19:15, Maciej Fijalkowski wrote:
Why would I want to run AF_XDP without ZC? The main reason for having AF_XDP
support in drivers is the zero copy, right?
In general I agree with you on this point. Short-term, I see copy-mode
useful for API adoption reasons (as XDP_SKB), so from th
On Fri, 14 Jun 2019 13:25:24 +
Maxim Mikityanskiy wrote:
> On 2019-06-13 17:45, Maciej Fijalkowski wrote:
> > On Thu, 13 Jun 2019 14:01:39 +
> > Maxim Mikityanskiy wrote:
> >
> >> On 2019-06-12 23:23, Jakub Kicinski wrote:
> >>> On Wed, 12 Jun 2019 15:56:48 +, Maxim Mikityanskiy
On 2019-06-13 17:45, Maciej Fijalkowski wrote:
> On Thu, 13 Jun 2019 14:01:39 +
> Maxim Mikityanskiy wrote:
>
>> On 2019-06-12 23:23, Jakub Kicinski wrote:
>>> On Wed, 12 Jun 2019 15:56:48 +, Maxim Mikityanskiy wrote:
Currently, libbpf uses the number of combined channels as the maxi
On 2019-06-13 21:09, Jakub Kicinski wrote:
> On Thu, 13 Jun 2019 14:01:39 +, Maxim Mikityanskiy wrote:
>> On 2019-06-12 23:23, Jakub Kicinski wrote:
>>> On Wed, 12 Jun 2019 15:56:48 +, Maxim Mikityanskiy wrote:
Currently, libbpf uses the number of combined channels as the maximum
On Thu, 13 Jun 2019 14:01:39 +, Maxim Mikityanskiy wrote:
> On 2019-06-12 23:23, Jakub Kicinski wrote:
> > On Wed, 12 Jun 2019 15:56:48 +, Maxim Mikityanskiy wrote:
> >> Currently, libbpf uses the number of combined channels as the maximum
> >> queue number. However, the kernel has a diff
On Thu, 13 Jun 2019 14:41:30 +0200, Björn Töpel wrote:
> On Wed, 12 Jun 2019 at 22:24, Jakub Kicinski
> wrote:
> >
> > On Wed, 12 Jun 2019 15:56:48 +, Maxim Mikityanskiy wrote:
> > > Currently, libbpf uses the number of combined channels as the maximum
> > > queue number. However, the kernel
On Wed, 12 Jun 2019 at 22:24, Jakub Kicinski
wrote:
>
> On Wed, 12 Jun 2019 15:56:48 +, Maxim Mikityanskiy wrote:
> > Currently, libbpf uses the number of combined channels as the maximum
> > queue number. However, the kernel has a different limitation:
> >
> > - xdp_reg_umem_at_qid() allows u
On 2019-06-12 23:23, Jakub Kicinski wrote:
> On Wed, 12 Jun 2019 15:56:48 +, Maxim Mikityanskiy wrote:
>> Currently, libbpf uses the number of combined channels as the maximum
>> queue number. However, the kernel has a different limitation:
>>
>> - xdp_reg_umem_at_qid() allows up to max(RX queu
On Thu, 13 Jun 2019 14:01:39 +
Maxim Mikityanskiy wrote:
> On 2019-06-12 23:23, Jakub Kicinski wrote:
> > On Wed, 12 Jun 2019 15:56:48 +, Maxim Mikityanskiy wrote:
> >> Currently, libbpf uses the number of combined channels as the maximum
> >> queue number. However, the kernel has a dif
On Wed, 12 Jun 2019 15:56:48 +, Maxim Mikityanskiy wrote:
> Currently, libbpf uses the number of combined channels as the maximum
> queue number. However, the kernel has a different limitation:
>
> - xdp_reg_umem_at_qid() allows up to max(RX queues, TX queues).
>
> - ethtool_set_channels() ch
Currently, libbpf uses the number of combined channels as the maximum
queue number. However, the kernel has a different limitation:
- xdp_reg_umem_at_qid() allows up to max(RX queues, TX queues).
- ethtool_set_channels() checks for UMEMs in queues up to
combined_count + max(rx_count, tx_count).
13 matches
Mail list logo
