> On Wed, Feb 3, 2021 at 3:14 PM wrote:
> >
> > We can test on x86 PC. We will just need about a week after you release
> your next version.
> >
>
> That's great. If you have any suggestions on how I can improve testing on my
> end, feel free to reach out.
If you are able, in addition to basic r
On Wed, Feb 3, 2021 at 3:14 PM wrote:
>
> We can test on x86 PC. We will just need about a week after you release your
> next version.
>
That's great. If you have any suggestions on how I can improve testing
on my end, feel free to reach out.
iller
> ; Jakub Kicinski ; Andrew Lunn
> ; Alexey Denisov ; Sergej Bauer
> ; Tim Harvey ; Anders
> Rønningen ; netdev
> ; Linux Kernel Mailing List ker...@vger.kernel.org>
> Subject: Re: [PATCH net-next v1 2/6] lan743x: support rx multi-buffer
> packets
>
> EXTERNAL
Thank you Bryan. I will prepare a v2 early next week.
Would Microchip be able to donate some time to test v2? My own tests
are certainly not perfect. Various stress tests across architectures
(intel/arm) would help create confidence in the multi-buffer frame
implementation. Perhaps Microchip has v
Hi Sven, see below
> >
> > If lan743x_rx_init_ring_element fails to allocate an skb, Then
> > lan743x_rx_reuse_ring_element will be called.
> > But that function expects the skb is already allocated and dma mapped.
> > But the dma was unmapped above.
>
> Good catch. I think you're right, the skb
On Sun, Jan 31, 2021 at 2:06 AM wrote:
>
> > static int lan743x_rx_process_packet(struct lan743x_rx *rx) {
> It looks like this function no longer processes a packet, but rather only
> processes a single buffer.
> So perhaps it should be renamed to lan743x_rx_process_buffer, so it is not
> mis
Hi Sven,
Looks good.
see comments below.
> static int lan743x_rx_process_packet(struct lan743x_rx *rx) {
It looks like this function no longer processes a packet, but rather only
processes a single buffer.
So perhaps it should be renamed to lan743x_rx_process_buffer, so it is not
misleading.
On Fri, Jan 29, 2021 at 6:08 PM Willem de Bruijn
wrote:
>
> Okay. I found it a bit hard to parse how much true code change was
> mixed in with just reindenting existing code. If a lot, then no need
> to split of the code refactor.
Thank you. The code is quite hard to review in patch format.
Proba
On Fri, Jan 29, 2021 at 6:03 PM Sven Van Asbroeck wrote:
>
> Hoi Willem, thanks a lot for reviewing this patch, much appreciated !!
>
> On Fri, Jan 29, 2021 at 5:11 PM Willem de Bruijn
> wrote:
> >
> > > +static struct sk_buff *
> > > +lan743x_rx_trim_skb(struct sk_buff *skb, int frame_length)
>
Hoi Willem, thanks a lot for reviewing this patch, much appreciated !!
On Fri, Jan 29, 2021 at 5:11 PM Willem de Bruijn
wrote:
>
> > +static struct sk_buff *
> > +lan743x_rx_trim_skb(struct sk_buff *skb, int frame_length)
> > +{
> > + if (skb_linearize(skb)) {
>
> Is this needed? That will
On Fri, Jan 29, 2021 at 2:56 PM Sven Van Asbroeck wrote:
>
> From: Sven Van Asbroeck
>
> Multi-buffer packets enable us to use rx ring buffers smaller than
> the mtu. This will allow us to change the mtu on-the-fly, without
> having to stop the network interface in order to re-size the rx
> ring
From: Sven Van Asbroeck
Multi-buffer packets enable us to use rx ring buffers smaller than
the mtu. This will allow us to change the mtu on-the-fly, without
having to stop the network interface in order to re-size the rx
ring buffers.
This is a big change touching a key driver function (process_
12 matches
Mail list logo