Re: refactor mbuf parsing on driver level

2023-02-07 Thread Alexander Bluhm
On Thu, Jan 26, 2023 at 11:37:51AM +0100, Christian Weisgerber wrote: > Jan Klemkow: > > > we have several drivers which have to parse the content of mbufs. This > > diff suggest a central parsing function for this. Thus, we can reduce > > redundant code. > > > > I just start with ix(4) and

Re: refactor mbuf parsing on driver level

2023-02-07 Thread Paul de Weerd
On Tue, Feb 07, 2023 at 01:09:25AM +0100, Christian Weisgerber wrote: | Jan Klemkow: | | > > igc(4) has very similar code, but I don't have access to a machine | > > with that hardware. | > | > Send me an ssh-key and I give you access to this machine: | | Alternatively, here's the diff, so

Re: refactor mbuf parsing on driver level

2023-02-06 Thread Florian Obser
On 2023-02-07 01:35 +01, Alexander Bluhm wrote: > On Tue, Jan 31, 2023 at 11:32:44PM +0100, Jan Klemkow wrote: >> On Tue, Jan 31, 2023 at 09:12:51PM +0100, Christian Weisgerber wrote: >> > > - Check if the mbuf is large enough for an ether header. > >> if (m == NULL || m->m_len - hoff <

Re: refactor mbuf parsing on driver level

2023-02-06 Thread Theo de Raadt
I hope this API and the way drivers use it is sufficient for strict-alignment architectures.

Re: refactor mbuf parsing on driver level

2023-02-06 Thread Theo de Raadt
Alexander Bluhm wrote: > > > > - additionally #ifdef'd INET6 around the ip6_hdr in the new struct > > Why? Usually I prefer the same struct size also for non generic > kernels. If you compile special kernels, user land debugging tools > behave stange and counting bytes in ddb gets hard. No

Re: refactor mbuf parsing on driver level

2023-02-06 Thread Alexander Bluhm
On Tue, Jan 31, 2023 at 11:32:44PM +0100, Jan Klemkow wrote: > On Tue, Jan 31, 2023 at 09:12:51PM +0100, Christian Weisgerber wrote: > > > - I turned the KASSERTS to returns. The old code only parsed the TCP|UDP header if the driver needed it and M_(TCP|UDP)_CSUM_OUT was set. So we may have

Re: refactor mbuf parsing on driver level

2023-02-06 Thread Christian Weisgerber
Jan Klemkow: > > igc(4) has very similar code, but I don't have access to a machine > > with that hardware. > > Send me an ssh-key and I give you access to this machine: Alternatively, here's the diff, so other people can test it. diff a0c537a1c9d84e98322b55d8f71438a147aaa7c4

Re: refactor mbuf parsing on driver level

2023-02-06 Thread Jan Klemkow
On Mon, Feb 06, 2023 at 09:47:57PM +0100, Christian Weisgerber wrote: > Christian Weisgerber: > > > I also switched over em(4) to this and have successfully used it > > for a full 30-hour package build on the four amd64 ports machines > > with their I350 interfaces. Additionally, I've done some

Re: refactor mbuf parsing on driver level

2023-02-06 Thread Christian Weisgerber
Christian Weisgerber: > I also switched over em(4) to this and have successfully used it > for a full 30-hour package build on the four amd64 ports machines > with their I350 interfaces. Additionally, I've done some IPv6 > testing at home over an I210. ok for this? igc(4) has very similar

Re: refactor mbuf parsing on driver level

2023-02-05 Thread Christian Weisgerber
Jan Klemkow: > > > - I turned the KASSERTS to returns. > > > - Check if the mbuf is large enough for an ether header. > > > - additionally #ifdef'd INET6 around the ip6_hdr in the new struct > > > > For non-initial fragments of TCP/UDP packets, ether_extract_headers() > > will create

Re: refactor mbuf parsing on driver level

2023-01-31 Thread Jan Klemkow
On Tue, Jan 31, 2023 at 09:12:51PM +0100, Christian Weisgerber wrote: > Jan Klemkow: > > > - I turned the KASSERTS to returns. > > - Check if the mbuf is large enough for an ether header. > > - additionally #ifdef'd INET6 around the ip6_hdr in the new struct > > For non-initial fragments of

Re: refactor mbuf parsing on driver level

2023-01-31 Thread Christian Weisgerber
Jan Klemkow: > - I turned the KASSERTS to returns. > - Check if the mbuf is large enough for an ether header. > - additionally #ifdef'd INET6 around the ip6_hdr in the new struct For non-initial fragments of TCP/UDP packets, ether_extract_headers() will create ext.tcp/ext.udp pointers that do

Re: refactor mbuf parsing on driver level

2023-01-30 Thread Jan Klemkow
On Fri, Jan 27, 2023 at 04:44:36PM +0100, Christian Weisgerber wrote: > > The ether_extract_headers() diff was reverted, because is wrong for the > > cases other than tcp/udp/icmp. We need to fix it and recommit again > > before continue. > > I think (TCP or) UDP fragments are the problem.

Re: refactor mbuf parsing on driver level

2023-01-27 Thread Christian Weisgerber
Vitaliy Makkoveev: > The ether_extract_headers() diff was reverted, because is wrong for the > cases other than tcp/udp/icmp. We need to fix it and recommit again > before continue. I think (TCP or) UDP fragments are the problem. Fragments don't have the protocol header but will still end up

Re: refactor mbuf parsing on driver level

2023-01-26 Thread Jan Klemkow
On Thu, Jan 26, 2023 at 02:06:28PM +0300, Vitaliy Makkoveev wrote: > On Thu, Jan 26, 2023 at 11:37:51AM +0100, Christian Weisgerber wrote: > > Jan Klemkow: > > > > > we have several drivers which have to parse the content of mbufs. This > > > diff suggest a central parsing function for this.

Re: refactor mbuf parsing on driver level

2023-01-26 Thread Vitaliy Makkoveev
On Thu, Jan 26, 2023 at 11:37:51AM +0100, Christian Weisgerber wrote: > Jan Klemkow: > > > we have several drivers which have to parse the content of mbufs. This > > diff suggest a central parsing function for this. Thus, we can reduce > > redundant code. > > > > I just start with ix(4) and

Re: refactor mbuf parsing on driver level

2023-01-26 Thread Christian Weisgerber
Jan Klemkow: > we have several drivers which have to parse the content of mbufs. This > diff suggest a central parsing function for this. Thus, we can reduce > redundant code. > > I just start with ix(4) and ixl(4) because it was easy to test for me. > But, this could also improve em(4),

Re: refactor mbuf parsing on driver level

2023-01-24 Thread David Gwynne
> On 25 Jan 2023, at 02:27, Vitaliy Makkoveev wrote: > > > >> On 24 Jan 2023, at 19:21, Jan Klemkow wrote: >> >> On Tue, Jan 24, 2023 at 05:40:55PM +0300, Vitaliy Makkoveev wrote: >>> On Tue, Jan 24, 2023 at 03:14:36PM +0100, Jan Klemkow wrote: On Tue, Jan 24, 2023 at 09:32:53PM

Re: refactor mbuf parsing on driver level

2023-01-24 Thread Vitaliy Makkoveev
> On 24 Jan 2023, at 19:21, Jan Klemkow wrote: > > On Tue, Jan 24, 2023 at 05:40:55PM +0300, Vitaliy Makkoveev wrote: >> On Tue, Jan 24, 2023 at 03:14:36PM +0100, Jan Klemkow wrote: >>> On Tue, Jan 24, 2023 at 09:32:53PM +1000, David Gwynne wrote: On Mon, Jan 23, 2023 at 09:25:34AM

Re: refactor mbuf parsing on driver level

2023-01-24 Thread Jan Klemkow
On Tue, Jan 24, 2023 at 05:40:55PM +0300, Vitaliy Makkoveev wrote: > On Tue, Jan 24, 2023 at 03:14:36PM +0100, Jan Klemkow wrote: > > On Tue, Jan 24, 2023 at 09:32:53PM +1000, David Gwynne wrote: > > > On Mon, Jan 23, 2023 at 09:25:34AM +0100, Jan Klemkow wrote: > > > > On Wed, Jan 18, 2023 at

Re: refactor mbuf parsing on driver level

2023-01-24 Thread Vitaliy Makkoveev
On Tue, Jan 24, 2023 at 03:14:36PM +0100, Jan Klemkow wrote: > On Tue, Jan 24, 2023 at 09:32:53PM +1000, David Gwynne wrote: > > On Mon, Jan 23, 2023 at 09:25:34AM +0100, Jan Klemkow wrote: > > > On Wed, Jan 18, 2023 at 03:49:25PM -0700, Theo de Raadt wrote: > > > > Jan Klemkow wrote: > > > > >

Re: refactor mbuf parsing on driver level

2023-01-24 Thread Jan Klemkow
On Tue, Jan 24, 2023 at 09:32:53PM +1000, David Gwynne wrote: > On Mon, Jan 23, 2023 at 09:25:34AM +0100, Jan Klemkow wrote: > > On Wed, Jan 18, 2023 at 03:49:25PM -0700, Theo de Raadt wrote: > > > Jan Klemkow wrote: > > > > On Wed, Jan 18, 2023 at 10:50:25AM +0300, Vitaliy Makkoveev wrote: > > >

Re: refactor mbuf parsing on driver level

2023-01-19 Thread Vitaliy Makkoveev
> On 19 Jan 2023, at 23:17, Jan Klemkow wrote: > > On Thu, Jan 19, 2023 at 02:55:29PM +0300, Vitaliy Makkoveev wrote: >> On Thu, Jan 19, 2023 at 10:40:52AM +0100, Jan Klemkow wrote: >>> On Thu, Jan 19, 2023 at 12:02:29PM +0300, Vitaliy Makkoveev wrote: On Thu, Jan 19, 2023 at 01:55:57AM

Re: refactor mbuf parsing on driver level

2023-01-19 Thread Jan Klemkow
On Thu, Jan 19, 2023 at 02:55:29PM +0300, Vitaliy Makkoveev wrote: > On Thu, Jan 19, 2023 at 10:40:52AM +0100, Jan Klemkow wrote: > > On Thu, Jan 19, 2023 at 12:02:29PM +0300, Vitaliy Makkoveev wrote: > > > On Thu, Jan 19, 2023 at 01:55:57AM +0300, Vitaliy Makkoveev wrote: > > > > > On 19 Jan

Re: refactor mbuf parsing on driver level

2023-01-19 Thread Vitaliy Makkoveev
On Thu, Jan 19, 2023 at 10:40:52AM +0100, Jan Klemkow wrote: > On Thu, Jan 19, 2023 at 12:02:29PM +0300, Vitaliy Makkoveev wrote: > > On Thu, Jan 19, 2023 at 01:55:57AM +0300, Vitaliy Makkoveev wrote: > > > > On 19 Jan 2023, at 01:39, Jan Klemkow wrote: > > > > > > > > On Wed, Jan 18, 2023 at

Re: refactor mbuf parsing on driver level

2023-01-19 Thread Jan Klemkow
On Thu, Jan 19, 2023 at 12:02:29PM +0300, Vitaliy Makkoveev wrote: > On Thu, Jan 19, 2023 at 01:55:57AM +0300, Vitaliy Makkoveev wrote: > > > On 19 Jan 2023, at 01:39, Jan Klemkow wrote: > > > > > > On Wed, Jan 18, 2023 at 10:50:25AM +0300, Vitaliy Makkoveev wrote: > > >> On Tue, Jan 17, 2023 at

Re: refactor mbuf parsing on driver level

2023-01-19 Thread Vitaliy Makkoveev
On Thu, Jan 19, 2023 at 01:55:57AM +0300, Vitaliy Makkoveev wrote: > > On 19 Jan 2023, at 01:39, Jan Klemkow wrote: > > > > On Wed, Jan 18, 2023 at 10:50:25AM +0300, Vitaliy Makkoveev wrote: > >> On Tue, Jan 17, 2023 at 11:09:17PM +0100, Jan Klemkow wrote: > >>> we have several drivers which

Re: refactor mbuf parsing on driver level

2023-01-18 Thread Vitaliy Makkoveev
> On 19 Jan 2023, at 01:39, Jan Klemkow wrote: > > On Wed, Jan 18, 2023 at 10:50:25AM +0300, Vitaliy Makkoveev wrote: >> On Tue, Jan 17, 2023 at 11:09:17PM +0100, Jan Klemkow wrote: >>> we have several drivers which have to parse the content of mbufs. This >>> diff suggest a central parsing

Re: refactor mbuf parsing on driver level

2023-01-18 Thread Theo de Raadt
Jan Klemkow wrote: > On Wed, Jan 18, 2023 at 10:50:25AM +0300, Vitaliy Makkoveev wrote: > > On Tue, Jan 17, 2023 at 11:09:17PM +0100, Jan Klemkow wrote: > > > we have several drivers which have to parse the content of mbufs. This > > > diff suggest a central parsing function for this. Thus, we

Re: refactor mbuf parsing on driver level

2023-01-18 Thread Jan Klemkow
On Wed, Jan 18, 2023 at 10:50:25AM +0300, Vitaliy Makkoveev wrote: > On Tue, Jan 17, 2023 at 11:09:17PM +0100, Jan Klemkow wrote: > > we have several drivers which have to parse the content of mbufs. This > > diff suggest a central parsing function for this. Thus, we can reduce > > redundant

Re: refactor mbuf parsing on driver level

2023-01-17 Thread Vitaliy Makkoveev
On Wed, Jan 18, 2023 at 10:50:25AM +0300, Vitaliy Makkoveev wrote: > On Tue, Jan 17, 2023 at 11:09:17PM +0100, Jan Klemkow wrote: > > Hi, > > > > we have several drivers which have to parse the content of mbufs. This > > diff suggest a central parsing function for this. Thus, we can reduce > >

Re: refactor mbuf parsing on driver level

2023-01-17 Thread Vitaliy Makkoveev
On Tue, Jan 17, 2023 at 11:09:17PM +0100, Jan Klemkow wrote: > Hi, > > we have several drivers which have to parse the content of mbufs. This > diff suggest a central parsing function for this. Thus, we can reduce > redundant code. > > I just start with ix(4) and ixl(4) because it was easy to

refactor mbuf parsing on driver level

2023-01-17 Thread Jan Klemkow
Hi, we have several drivers which have to parse the content of mbufs. This diff suggest a central parsing function for this. Thus, we can reduce redundant code. I just start with ix(4) and ixl(4) because it was easy to test for me. But, this could also improve em(4), igc(4), ale(4) and oce(4).