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
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
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 <
I hope this API and the way drivers use it is sufficient for strict-alignment
architectures.
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
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
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
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
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
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
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
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
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.
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
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.
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
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),
> 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
> 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
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
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:
> > > > >
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:
> > >
> 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
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
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
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
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
> 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
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
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
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
> >
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
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).
33 matches
Mail list logo