> I must look at how to determine that disks have 4k sectors and to
> ensure filesystesm have 4k fragments - regardless of the fs size.
Seems to me the right thing is to believe what the disk tells you. If
you really want to be friendly to broken hardware, add a quirk for
disks known to lie about
Brian Buhrow writes:
> However, some drivers, i.e. stge(4), send the packet to the bpf engine after
> step 2, above, before performing steps 3, 4 and 6. Without having tested
> anything yet, this seems more correct to me.
> I will try to get a test environment together with some chips cap
On Mon, Nov 26, 2012 at 03:06:34PM +0100, J. Hannken-Illjes wrote:
> In short the attached diff:
>
> - Adds a new kernel-internal errno ERESTARTVOP and changes VCALL() to
> restart a vnode operation once it returns ERESTARTVOP.
>
> - Changes fstrans_start() to take an optional `hint vnode
On Nov 29, 2012, at 5:17 PM, David Holland wrote:
> On Mon, Nov 26, 2012 at 03:06:34PM +0100, J. Hannken-Illjes wrote:
>> In short the attached diff:
>>
>> - Adds a new kernel-internal errno ERESTARTVOP and changes VCALL() to
>> restart a vnode operation once it returns ERESTARTVOP.
>>
>> - Ch
On Wed, Nov 28, 2012 at 07:23:13PM -0600, David Young wrote:
> On Wed, Nov 28, 2012 at 07:27:56PM -0500, Greg Troxel wrote:
> >
> > dhcpd, last I checked, used bpf and not sockets.
> >
> > If dhcpd is bpf, I would suggest reading the bpf_tap calls in the
> > driver. It could be that if_wm.c has
hello. Ok. I think I have a better understanding of what is
happening. It's important to understand that in our stack, regardless of
whether or not hardware vlan tagging is enable, the bpf engine sees all
packets with vlan tags twice: first from the ethernet driver itself and
second fr
On 29 Nov, 2012, at 08:23 , Greg Troxel wrote:
> bpf is supposed to present the packet as it should have been received on
> the interface. In the presence of hardware acceleration, that's a
> tricky concept.
>
> When a packet arrives that has vlan tag, it makes sense to have it
> bpf_tap'd on t
Brian Buhrow writes:
> [lots of details]
Everything you said sounds ok to me.
> Fortunately, I believe there is an easy fix for this problem which
> preserves our ability to support the vlan extraction features of modern
> ethernet chips while preserving the historical behavior of the Ne
On 29 Nov, 2012, at 13:52 , Manuel Bouyer wrote:
> On Wed, Nov 28, 2012 at 07:23:13PM -0600, David Young wrote:
>> On Wed, Nov 28, 2012 at 07:27:56PM -0500, Greg Troxel wrote:
>>>
>>> dhcpd, last I checked, used bpf and not sockets.
>>>
>>> If dhcpd is bpf, I would suggest reading the bpf_tap
> I'm also trying hard, but failing, to ignore the issue which revealed
> the current problem, that being having an application as important as
> a DHCP client needing to use BPF to send and receive UDP packets
> rather than using the host's own UDP/IP code for that.
I'm not sure I'd call that an
10 matches
Mail list logo
